You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is incredibly useful to log things as the spec executes
e.g., we manually add log commands around memory operations.
Traces can be used either by humans for debugging or they can be used in checkers for testing.
But, adding these log commands adds clutter to the specification and tends to be a bit specific to the particular use case.
Sketch of a plan
We could automatically insert logging commands into the ASL code using some variant of Aspect Oriented Programming. There are two parts to this.
Where should log commands be inserted? (i.e., "pointcut specification" that specifies a set of "join points")
The easy places to insert logging are at the start of a function, at each return point of a function and, optionally, when a function throws an exception. These are easy because it is clear what we would want to log (arguments and results) and it is clear where the entry/exit-point of a function is.
(Complication: sometimes we want to log the values of global variables too. For example, what privilege level are we calling the function in?)
Large specs tend to have naming conventions for functions so regular expressions are an obvious way of specify groups of functions.
Putting this information is a yaml/json file is convenient because it makes it easier to machine-generate lists.
What code should be inserted?
The most obvious thing to insert is a print statement (see (Semi)Planned extension: "printf" #30) to produce human-readable debugging.
But it is also useful to generate machine-readable output.
And it is useful to generate foreign function calls - e.g., calling out to an external library to support some form of cosimulation.
Also, note that the code at each join point might need to be different so we will want a way to say "all function arguments" or all return values.
Can we avoid putting this complexity into ASLi and instead rely on external scripts to generate json files that do most of the hard work?
The text was updated successfully, but these errors were encountered:
Motivation
It is incredibly useful to log things as the spec executes
e.g., we manually add log commands around memory operations.
Traces can be used either by humans for debugging or they can be used in checkers for testing.
But, adding these log commands adds clutter to the specification and tends to be a bit specific to the particular use case.
Sketch of a plan
We could automatically insert logging commands into the ASL code using some variant of Aspect Oriented Programming. There are two parts to this.
Where should log commands be inserted? (i.e., "pointcut specification" that specifies a set of "join points")
The easy places to insert logging are at the start of a function, at each return point of a function and, optionally, when a function throws an exception. These are easy because it is clear what we would want to log (arguments and results) and it is clear where the entry/exit-point of a function is.
(Complication: sometimes we want to log the values of global variables too. For example, what privilege level are we calling the function in?)
Large specs tend to have naming conventions for functions so regular expressions are an obvious way of specify groups of functions.
Putting this information is a yaml/json file is convenient because it makes it easier to machine-generate lists.
What code should be inserted?
The most obvious thing to insert is a print statement (see (Semi)Planned extension: "printf" #30) to produce human-readable debugging.
But it is also useful to generate machine-readable output.
And it is useful to generate foreign function calls - e.g., calling out to an external library to support some form of cosimulation.
Also, note that the code at each join point might need to be different so we will want a way to say "all function arguments" or all return values.
Can we avoid putting this complexity into ASLi and instead rely on external scripts to generate json files that do most of the hard work?
The text was updated successfully, but these errors were encountered: