[cfe-dev] DebugInfo: Template names

[David Blaikie via cfe-dev]

On Mon, Nov 22, 2021 at 5:15 PM <paul.robinson at sony.com> wrote:

> 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.
>

Fair - though the global variable might be in a library/code not built with
debug info enabled. Static variables might be harder to miss - since they'd
be in the same translation unit/compilation unit. Or if the global is
optimized out, then you might not be able to identify which global variable
(even if it is described by the DWARF) is the one referenced by this
non-type template parameter DWARF description. (perhaps we should/could
improve this DWARF by referring to a declaration or definition of the
actual variable, with a location on /that/ DWARF description instead of
directly in the template parameter description... if that covers all the
cases for C++, which I /think/ it does (as you say, you can't reference an
element of an array in a non-type template parameter, it has to be a whole
named variable, I think))


> 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.
>

 Yeah - ELF linkers generally don't want to special-case the debug info
sections (the idea being that ELF is DWARF agnostic - but it isn't
entirely, the tombstoning logic (which value to use for dead references/how
to make those references dead) is one of those things). I /guess/ the
linker is OK discarding the referenced functions, but has to have a
reference to it first or it produces an error about unresolved
relocations... - but maybe it doesn't actually cause the code to be linked
in?

Hmm, maybe it works for function pointers but has been overlooked/not
implemented for data pointers in some way...:

$ cat test.cpp

template<int *x, void (*y)()>

void f1() { }

void f2();

extern int i;

int main() {

  f1<&i, f2>();

}

$ cat test2.cpp

#include <iostream>

extern int i;

int i = ((std::cout << "Hello, World.\n"), 1);

$ clang++-tot test.cpp test2.cpp -c && clang++-tot test.o -Wl,--start-lib
-Wl,test2.o -Wl,--end-lib -fuse-ld=lld && ./a.out

$ clang++-tot -g test.cpp test2.cpp -c && clang++-tot test.o
-Wl,--start-lib -Wl,test2.o -Wl,--end-lib -fuse-ld=lld && ./a.out

Hello, World.

$ nm a.out | grep " i$"

0000000000203d48 B* i*

$ clang++-tot test.cpp test2.cpp -c && clang++-tot test.o -Wl,--start-lib
-Wl,test2.o -Wl,--end-lib -fuse-ld=lld && ./a.out

$ nm a.out | grep " i$"

$ clang++-tot test.cpp test2.cpp -c -ffunction-sections -fdata-sections &&
clang++-tot -Wl,-gc-sections test.o -Wl,--start-lib -Wl,test2.o
-Wl,--end-lib -fuse-ld=lld && ./a.out

$ nm a.out | grep " i$"

$ ./a.out

$ clang++-tot -g test.cpp test2.cpp -c -ffunction-sections -fdata-sections
&& clang++-tot -Wl,-gc-sections test.o -Wl,--start-lib -Wl,test2.o
-Wl,--end-lib -fuse-ld=lld && ./a.out

Hello, World.

$ nm a.out | grep " i$"

0000000000203d04 B* i*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211123/a3188626/attachment.html>