| Summary: | Support -g debug info generation | ||
|---|---|---|---|
| Product: | RMAC | Reporter: | James Jones <atari> |
| Component: | Core | Assignee: | Shamus Hammons <jlhamm> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | bs42, ggnkua, jlhamm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
General plumbing for debug symbol handling
Generate source-level gstabs debugging symbols when requested General plumbing for debug symbol handling Generate source-level gstabs debugging symbols when requested |
||
|
Description
James Jones
2022-07-25 00:53:20 CDT
Created attachment 189 [details]
General plumbing for debug symbol handling
Created attachment 190 [details] Generate source-level gstabs debugging symbols when requested This patch completes the series. Compilation only tested on Linux, and there's one win32/Linux ifdef here someone should probably check. Tested the debug symbol output using "size" utility (Version 2.24+) from my jag_utils repo: https://github.com/cubanismo/jag_utils. It will dump all debug symbols from an a.out object file or .cof absolute binary using "size -v0 -sd <file>", as well as loading linked executables using object files from this version of RMAC into gdbjag (From my Jaguar SDK: https://github.com/cubanismo/jaguar-sdk), WDB, and RDBJAG (The original Atari debuggers, also available in my SDK repo, but only usable if you have an Alpine board and a computer that can talk to it). Hello, First of all, thanks for the patches! I'm happy to report that our current regression test suite passes cleanly after applying the patches, so nothing broke - I'm fine with that! I have a couple of nitpicks in the code while I was browsing the patches, so allow me to share them with you: a) In patch #1, symbol.c, NewSymbol() you seem to be zeroing the new fields st_desc, st_other with every new symbol created, but as you say they are only used when creating debug symbols. So I think the best place for them would be inside NewDebugSymbol(). Would you agree? b) In patch #2 you seem to have added a call to GenLineNoSym() with every line assembled. So in practice the CPU has to jump to that function, check if dsym_flag is zero, then exit if it's not. I'm not very happy with this as it adds unnecessary calls to the critical path. I would like to see something like the following instead of the GenLineNoSym() calls: if (dsym_flag) GenLineNoSym(); If this looks too gnarly, no problem making a macro out of it: #define GENLINENOSYM if (dsym_flag) GenLineNoSym(); I'd feel much better with either of the above! (Yes yes I know, it's a stupid tool, but I like that it's running fast and I try to keep it running fast if I can help it) That's it for now. Waiting for your comments... My 2cnts: From the "clean code" paradigm, the test dsym_flag should be placed inside the function. On modern CPUs with giant caches, you won't notice a difference, but code gets more readable and maintainable. At this point I'd like to state that occasionally I do build rmac for the Atari ST, as some friends actually like to assemble code on the real machine, especially when testing their demo code. So there's a good enough reason :) Created attachment 195 [details]
General plumbing for debug symbol handling
Created attachment 196 [details]
Generate source-level gstabs debugging symbols when requested
I've applied both your suggestions and re-tested (Uhg, see bug 207). The GENLINENOSYM() macro seemed like a reasonable compromise to me, so I went with that. All checks out here, nicely done and thanks for the reworkings! Thanks for the patches! :-) |