Bug 4154 – Incorrect DWARF section names on Mac

Created attachment 622 Fixes the incorrect DWARF section names According to the Mach-O file format reference: http://developer.apple.com/Mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html section names should be all lowercase and prefixed with two underscores "__". DMD output the DWARF section names with a dot "." as the prefix instead of the two underscores. Both GCC and Clang output the DWARF section names prefixed with two underscores. I've attached a patch which fixes this. But with this patch (I think) one or several offsets somehow become incorrect. This is the output of dwarfdump --verify: The offset into the .debug_abbrev section (0xffffffff) is not valid. Maybe it's because the section names are now one character longer or there is something other that isn't working. The patch is against DMD revision 466.

The ABI says that the double-underscore prefix is a convention only and that any prefix will work, but I saw in the Valgrind source yesterday that it searches explicitly for a double-underscore prefix, and I suspect other apps are the same.

Exactly, as the documentation says it's just a convention. But all other tools/applications assume you follow the convention, that it starts with two underscores, gdb for example.

Today Walter merged a big batch of dwarf related fixes. I'm curious if these changes + those that were just submitted fix the other issues mentioned here. Could I get one of you two to update the patch here (if needed) and check to make sure it still works correctly?

(In reply to comment #3) > Today Walter merged a big batch of dwarf related fixes. I'm curious if these > changes + those that were just submitted fix the other issues mentioned here. > Could I get one of you two to update the patch here (if needed) and check to > make sure it still works correctly? I will not be able to try the patch until tuesday evening. I don't think it ever worked correctly, read my original message.

I have a modified version of this patch that almost works (one byte needs changing with a hex editor for debug info to work). I should have a patch/pull request together later tonight.

I've run out of time to work on this for now, my initial commit is at https://github.com/mrmonday/dmd/commit/c7fed0fbe5319de507fd0afb4c574bdb4e54699f . The debug info can easily be fixed up in a hex editor, I'm struggling to find where dmd is outputting the incorrect info though. In the __debug_info section the abbrev_offset field is being set to the incorrect value. The workaround is to change it to zero in a hex editor, this is not the correct solution though, the correct offset needs to be inserted.

Actually, removing the offset seems to be the correct solution - it's what both gcc and clang do on OS X (despite it being contrary to what the DWARF spec states). I'll put together a pull request now. Another odd side effect seems to be that no debug info ends up in the resulting binary (only the object files), but again, this seems to be consistent with gcc and clang's output when using -g. I recall reading somewhere that Mach-O uses a separate file for debug information, it could be related to this.

https://github.com/D-Programming-Language/dmd/pull/83 - Everything works as it should, the file just needs running through dsymutil. Unfortunately dsymutil exploded violently when I tried to get it working, so I didn't add it into dmd's builder.

(In reply to comment #8) > https://github.com/D-Programming-Language/dmd/pull/83 - Everything works as it > should, the file just needs running through dsymutil. I don't understand - why should dsymutil be needed at all? It isn't needed for gcc.

(In reply to comment #9) > I don't understand - why should dsymutil be needed at all? It isn't needed for > gcc. Au contraire - put the following in test.c: ---- int main() { return 0; } ---- then: $ gcc -v -g test.c -o test or $ clang -v -g test.c -o test You'll notice the last command run by either is dsymutil test.

I may have found what dsymutil is choking on, I can't be sure though - following the steps taken by gcc, then removing the object file it creates before running dsymutil causes dsymutil to complain that <object file> does not exist. Curious, I inspected the binary with a hex editor, and it appears ld left some information in there that dsymutil requires, a list of object files. It seems ld doesn't do this for dmd, so I suspect there's something else we're not outputting that's required, or some flag we need to pass to ld. I blame ld, as there is no mention of the object file(s) in themselves before linking. I'll hunt a bit further, I'm not sure how much I can do without more knowledge of what's going on.

So DMD should invoke dsymutil?

I believe so, there's not a lot of point right now though, given that the binaries produced by dmd cause dsymutil to fail. Struggling to find out what needs changing to stop dsymutil failing.

You don't need to run dsymutil. The final executables do usually not contain debug infos, but they do contain the path of all object files that were linked. Debuggers will use these to get the debug infos from the object files. Also GDB will load debug infos from the executable.

Is this still an issue or not?

Nope, the underscore fix is already in the compiler.