GDB: AmForth Stack Framing

[mkobetic]

It might be possible to make GDB backtrace usable with AmForth, the Google AI tips below might be worth checking out:

For significant customization, such as handling non-standard calling conventions or modifying how frame information is presented, GDB provides a powerful Python API.

Custom Unwinders:
You can write a custom gdb.Unwinder in Python to define how GDB should traverse the stack and locate frame information, especially useful for functions that omit frame pointers (e.g., those compiled with -fomit-frame-pointer) or use unusual stack layouts.

Frame Decorators and Filters:
Frame Decorators (gdb.FrameDecorator) allow you to modify the information associated with an existing frame object, such as changing how function names or arguments appear.
Frame Filters are used to register these decorators with GDB's global frame filter dictionary, allowing your custom logic to be applied to the stack trace output.

A possible solution might be:

• if we can somehow distinguish return IPs from other stuff on return stack we can build a frame for each of those
• if we could somehow capture parameter stack depth at each frame that would be awesome, that may require injecting markers into the return stack or a parallel stack indexing the return stack (a debug mode forth?)

[mkobetic]

A custom unwinder seems to be able to rebuild the backtrace as needed, with correct SP and PC values. There's no way to capture other register frame states without the runtime capturing more information, but that's OK. The basic stuff allows using basic frame commands effectively (up, down, ....).

The annoying part is that the symbols from colon words do not have correct line info associated with them. It seems AS only updates its internal "file line pointer" for symbols that point at actual executable instructions. Symbols that point at data directives (e.g. .word) get whatever the last value of the line pointer is. That's why most of the secondary colon words have ../words/move.s:40 attached to them, because that's where the last primary codeword that was compiled before is from.

There isn't really any workaround here. The "correct" way is to use .file and .loc directives for all the symbols. It seems that if you use it even once anywhere, AS will stop generating the automatic line info altogether (even for symbols pointing at instructions). So we might be stuck between a rock and a hard place here. Even if we start transpiling all colon words and generate .file and .loc directives as needed (which would make sense and have them point at the original forth files), then we would likely lose the automatic line info for code word sources. Not sure what we can do here.