[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