leonardt
commented
3 years ago Documenting from out slack discussion. Our initial approach will be:
- Use a separate debug pipeline than the existing stack based debug flow, which will still be useful for tracebacks directly to where in the source things occur.
- Rewrite the class code to insert a function call for every line that sets a global variable for current filename/linenumber
- Any instancing/wiring logic will attach this source information to their debug information
This will give users insight into where at the top level (class code) instances and wires are created. This should handle complex expressions and nested function invocations. In theory this should be faster than using inspect to traverse the stack, so it may be a good option for "fast" debug while providing useful information to the user to locate where in the source they should start looking for the source of certain wiring/instancing structures.
As a follow up step, we may be able to combine the two approaches (class level source information and stack based source information). This would give us a specific place in the code we could insert breakpoints/print statements for debugging. For example, the stack based source information might tell us that some helper function is creating a wire, but this helper function might be called in multiple places in different definitions. Using the class source level debug information, we can scope the print/breakpoint to a specific code path where the helper function is being used for the source code at the desired location in the class code. This avoids extraneous prints from other code paths, and should help the user focus on debugging the specific code path they're interested in.
Chisel uses macros to rewrite their code to pass in source filename/linenumber information. See this thread for more discussion: https://github.com/chipsalliance/chisel3/issues/147 We should review this carefully to understand the issues related to this approach.
The theory is that this should be faster than our current inspect debug pattern where every instance/wiring we have to pause the interpreter to fetch stack information and see where things are occurring. This is also fraught with corner cases, e.g. where there are levels of indirection.
This would also fit in with https://github.com/phanrahan/magma/issues/575, although I think our task here is a bit simpler since filename and linenumber should be straightforward. However there is an issue related to when the debug decorator is applied (e.g. if another decorator rewrites code, we may end up with mismatching line information). I think there should be away to integrate this with ast_tools so at least we can compose decorators (passes) and maintain this filename/linenumber information, but in general we may not be able to (or need to) support transforming decorators.