doesn't work with clang about libbacktrace

[ianlancetaylor]

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?

[jmberg]

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.