doesn't work with clang
jmberg opened this issue · comments
At least with later versions of clang, I get a .rel.debug_info section that actually puts the strp offsets into the .debug_info section, and because libbacktrace doesn't read the relocations, all my strings are just "clang version 9.0.0-svn351420-1~exp1 (trunk)" (which is the string at .debug_str 0x0 offset)
libbacktrace only works with a fully linked executable. Are you saying that clang generates an executable with a .rel.debug_info section? Is there any spec for that?
Yes, you're right, and I think we even had this discussion before. I've been using libbacktrace to extract debug data (like function prototypes) from object/archive files on disk - it's much faster than all the other alternative libraries I've looked at. I guess I'll close this.
But yes, to answer your questions: clang generates an executable with a .rel.debug_info section, specifically for strp entries. So when you normally have a strp entry with an offset into the .debug_str section (like a filename, function name, etc.) the actual offset into the .debug_str section isn't emitted directly into the .debug_info section, but as 0 instead there, with a relocation entry in the .rel.debug_info section that fixes it up.
I'm not sure there is or even has to be a spec for this, I suppose it'd be covered by the normal ELF relocation spec, just applied to the .debug_info section?
Now, overall, I don't really see any good reason for this - these entries aren't dynamic, they're just offsets into the string section, and I doubt clang gains anything by emitting things in this way. It makes the binary bigger by the .rel.debug_info section too. It could be that it does this because it emits the .debug_info section before the .debug_str section or so, but I can't really think of any fundamental reason for doing so - could build/emit them at around the same time and still dedup strings.
Interestingly I found that "objdump" is able to parse this, whereas "readelf" also doesn't expect this type of thing.