[cfe-dev] DebugInfo: Template names

via cfe-dev cfe-dev at lists.llvm.org
Mon Nov 22 17:15:43 PST 2021


Ah, yep. I thought about the possibility of actually doing symbol lookup - but that seemed a bit extreme to me (having to go outside the DWARF to figure out the name). Though that wouldn't work if the variable/function is optimized out (if it's defined in another object file and that isn't referenced/is omitted by the linker, or -Wl,-gc-sections, etc).

Don’t necessarily need to go outside the DWARF?  given that the symbol ought to have a DWARF description whose location expression should be the same address.  If you’ve already loaded the unit then the address-based lookup is feasible.  And in fact (for example) ELF symbol lookup isn’t going to work for a `static` item anyway, AFAICT only non-private symbols end up in the ELF symbol table.

There's some quirks here - for some reason these relocations used in the ELF file to write the address of the variables/functions for pointer non-type-template parameters into the DWARF data cause linker errors if those globals aren't defined (which leads to -g/-g0 codegen differences, since the linker is pulling in these symbols, could pull in global ctors in the objects that define those symbols, etc) but the symbols /can/ still be eliminated with -ffunction-sections f-data-sections -Wl,-gc-sections...

Hmm don’t think that references from .debug_* sections count as gc roots?  I may be mistaken, this might be a Sony-proprietary linker behavior and not something LLD does, but IMO that should be LLD’s behavior as well.  The relocations would end up as unresolved and be tombstoned.
--paulr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211123/bcfe38bd/attachment.html>


More information about the cfe-dev mailing list