Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planned feature: Logging support #31

Open
alastairreid opened this issue Feb 10, 2025 · 0 comments
Open

Planned feature: Logging support #31

alastairreid opened this issue Feb 10, 2025 · 0 comments

Comments

@alastairreid
Copy link

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.

  1. 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.

  2. 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant