[cfe-dev] DebugInfo: Template names

[David Blaikie via cfe-dev]

On Mon, Nov 22, 2021 at 11:02 AM <paul.robinson at sony.com> wrote:

> > Hey Paul - you mentioned the SCE debugger always rebuilds names
> > from the DWARF tags (after stripping the <...> suffix from the
> > DW_AT_name in the DWARF, I guess/assume?) - I was curious if you
> > (or others you could cc on this thread) know how that solution
> > deals with some of the more difficult issues I've punted on so
> > far with the Simplified Template Names work.
> >
> > The specific one that comes to mind is any pointer non-type
> > template parameters. (eg: "template<int*> void f1(); int g; ...
> > f1<&g>()" - so far as I know there's not enough data in the DWARF
> > to reconstruct that name.
>
> This one I'm pretty sure about: The template_value_parameter has
> a DW_AT_location that is the address of the actual parameter, and
> that address ought to be resolvable to "g" (at least once you have
> the linked image, it should be straightforward, because "g" would
> have a DWARF description whose location had that as the address).
> We don't have to worry about things like "&array[10]" because
> that's not legal for a non-type template parameter (as per
> [temp.arg.nontype]p3 in C++11).
>
> But I've asked anyway, to confirm.
>

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

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


> > The other one I came across was unnamed struct types V lambda
> > types - they have distinct manglings & so need different naming
> > I think? But the DWARF has no record of that, and probably
> > doesn't have enough data to reconstruct the original naming
> > (because the naming is based on the number of lambdas seen so
> > far - and the DWARF isn't adequately/guaranteed to be ordered
> > like the source and also may omit some types if they're unused
> > leading to holes in the numbering)
>
> I was recently unable to figure out how to pass a lambda as a
> template parameter, so if you could provide an example that would
> be helpful both for this question and the other thing I was doing.
> I've passed your description along just in case they know off the
> tops of their heads.
>

Oh, sure, consider code something like this:

template<typename T>

void f1() { }

class { } x;

auto y = [] { };

int main() {

  f1<decltype(x)>();

  f1<decltype(y)>();

}


$ clang++-tot test.cpp -g -c && llvm-dwarfdump-tot test.o | grep
"DW_AT_name\|DW_TAG\|DW_AT_type\|DW_AT_linkage"

0x0000000b: *DW_TAG*_compile_unit

              *DW_AT_name*        ("test.cpp")

0x0000002a:   *DW_TAG*_subprogram

                *DW_AT_name*      ("main")

                *DW_AT_type*      (0x00000089 "int")

0x00000043:   *DW_TAG*_subprogram

                *DW_AT_linkage*_name      ("_Z2f1I3$_0Evv")

                *DW_AT_name*      ("f1<(unnamed class at test.cpp:3:1)>")

0x0000005c:     *DW_TAG*_template_type_parameter

                  *DW_AT_type*    (0x00000090 "class ")

                  *DW_AT_name*    ("T")

0x00000066:   *DW_TAG*_subprogram

                *DW_AT_linkage*_name      ("_Z2f1I3$_1Evv")

                *DW_AT_name*      ("f1<(lambda at test.cpp:4:10)>")

0x0000007f:     *DW_TAG*_template_type_parameter

                  *DW_AT_type*    (0x00000095 "class ")

                  *DW_AT_name*    ("T")

0x00000089:   *DW_TAG*_base_type

                *DW_AT_name*      ("int")

0x00000090:   *DW_TAG*_class_type

0x00000095:   *DW_TAG*_class_type


Oh, I had thought these actually mangled differently, but they don't - so
if you rendered both as "unnamed class" that'd probably be OK! Clang/LLVM
only includes the line, and not the column, so you'd be able to render this
as "(unnamed class at test.cpp:3)" rather than "(unnamed class at
test.cpp:3:1)".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211122/659f009b/attachment-0001.html>