Bug 206 - Support -g debug info generation
Summary: Support -g debug info generation
Alias: None
Product: RMAC
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: All All
: Normal enhancement
Assignee: Shamus Hammons
Depends on:
Reported: 2022-07-25 00:53 CDT by James Jones
Modified: 2022-08-15 21:11 CDT (History)
3 users (show)

See Also:

General plumbing for debug symbol handling (6.88 KB, patch)
2022-07-25 00:54 CDT, James Jones
Generate source-level gstabs debugging symbols when requested (12.48 KB, patch)
2022-07-25 01:14 CDT, James Jones
General plumbing for debug symbol handling (7.08 KB, patch)
2022-07-26 06:16 CDT, James Jones
Generate source-level gstabs debugging symbols when requested (12.64 KB, patch)
2022-07-26 06:17 CDT, James Jones

Note You need to log in before you can comment on or make changes to this bug.
Description James Jones 2022-07-25 00:53:20 CDT
This patchset replicates the '-g' source-level debugging support found in later versions of MADMAC, allowing stepping through assembly listings at the source level in WDB, RDBJAG, and versions of GDB patched to be compatible with ALN/RLN's version of the COFF format (COFF file header + a.out symbol table).

It is not identical to MADMAC. The following differences are known:

-RMAC will resolve symbolic links in file paths when embedding them in assembly files. MADMAC appears to resolve the absolute path of a file from the current working directory and include paths.

-MADMAC appears to output debug symbols after all global and local symbols. RMAC interleaves the two based on their order of instantiation. ALN, RLN, and the debuggers don't seem to care either way.
Comment 1 James Jones 2022-07-25 00:54:12 CDT
Created attachment 189 [details]
General plumbing for debug symbol handling
Comment 2 James Jones 2022-07-25 01:14:01 CDT
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).
Comment 3 ggn 2022-07-25 08:33:23 CDT

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...
Comment 4 42Bastian 2022-07-25 09:28:16 CDT
My 2cnts:

From the "clean code" paradigm, the test 


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.
Comment 5 ggn 2022-07-25 09:39:58 CDT
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 :)
Comment 6 James Jones 2022-07-26 06:16:48 CDT
Created attachment 195 [details]
General plumbing for debug symbol handling
Comment 7 James Jones 2022-07-26 06:17:52 CDT
Created attachment 196 [details]
Generate source-level gstabs debugging symbols when requested
Comment 8 James Jones 2022-07-26 06:19:22 CDT
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.
Comment 9 ggn 2022-07-26 13:20:55 CDT
All checks out here, nicely done and thanks for the reworkings!
Comment 10 Shamus Hammons 2022-08-15 21:11:05 CDT
Thanks for the patches!  :-)