[cfe-dev] DebugInfo: Template names

[David Blaikie via cfe-dev]

On Thu, Dec 9, 2021 at 12:52 PM <paul.robinson at sony.com> wrote:

> I heard back from our debugger folks (actually they replied a couple weeks
> ago and I missed the notification somehow).  They compliment you on the
> interesting test cases. 😊
>

Thanks for checking into it!


> For the case of a pointer template parameter, “template<int*> void f1() {
> … }; int g; … f1<&g>();” where “g” has address 0x1234, this indeed would
> get reconstructed as “f1<0x1234>” although now that you’ve brought it up,
> they’ve raised an internal ticket to look at symbolizing that.  I agree
> with your point that if “g” is defined in another CU and not compiled with
> debug info, there might be no more than an external declaration in the
> current CU’s DWARF to look at, and so information outside of DWARF would be
> needed to symbolize that.  I don’t know about this case specifically but I
> have seen gdb make use of the ELF symbol table to derive information that
> isn’t present in the DWARF, so it’s not unprecedented.
>

Ah, yeah - might've seen something where gdb might've stitched up a
declaration in one CU, with no-debug definition in another object based on
the symbol name.


>   I think for your round-tripping purposes, if the symbol _*is*_ in the
> DWARF you could symbolize it, and for the other cases have to be content
> with falling back to the pointer literal.
>

I think the risk there, compiling with -ffunction-sections -fdata-sections
-Wl,--gc-sections is that the pointer literal might be zero if the symbol
has been gc'd, so it may not be recoverable/uniqueable.

$ cat test.cpp

template<int*> void f1() { }

static int a;

static int b;

int main() {

  f1<&a>();

  f1<&b>();

}

$ clang++-tot test.cpp -g && llvm-dwarfdump-tot a.out | grep DW_AT_location

...

                  *DW_AT_location*        (DW_OP_addr 0x40402c,
DW_OP_stack_value)

                  *DW_AT_location*        (DW_OP_addr 0x404030,
DW_OP_stack_value)

$ clang++-tot test.cpp -g -fdata-sections -Wl,--gc-sections &&
llvm-dwarfdump-tot a.out | grep DW_AT_location

...

                  *DW_AT_location*        (DW_OP_addr 0x0,
DW_OP_stack_value)

                  *DW_AT_location*        (DW_OP_addr 0x0,
DW_OP_stack_value)


> For the second case, using as example code
>
> template<typename T> void f1() {}
>
> class {} x;
>
> auto y = []{};
>
> int main() {
>
>   f1<decltype(x)>();
>
>   f1<decltype(y)>();
>
> }
>
>
>
> this conjures up generated names on the order of
>
> f1<(anon_class:0x4D62500372C58A1A)>
>
> f1<(anon_class:0x4D62500372C58A65)>
>
> which is admittedly not great, syntactically not identifiers for one
> thing.
>

Well, no worse than the compiler generated names, which also aren't
identifiers:
Clang:

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

f1<(lambda at test.cpp:5:10)>
GCC:

f1<<lambda()> >

f1<<unnamed class> >

At least it sounds like maybe the ones you have are unique (though I wonder
how they're uniqued across CUs to still generate the same identifier) -
GCC's certainly aren't, Clang's probably aren't (with sufficient macro goo):

$ cat test.cpp

template<typename T> void f1() {}


#define ANONS \

class {} a1; \

class {} a2

ANONS;


#define LAMBDAS \

auto l1 = []{}; \

auto l2 = []{}

LAMBDAS;


int main() {

  f1<decltype(a1)>();

  f1<decltype(a2)>();

  f1<decltype(l1)>();

  f1<decltype(l2)>();

}

$ clang++-tot test.cpp -g -c && llvm-dwarfdump-tot test.o | grep "f1<"

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

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

                DW_AT_name      ("*f1<*(lambda at test.cpp:11:1)>")

                DW_AT_name      ("*f1<*(lambda at test.cpp:11:1)>")

Not something anyone has complained about and so not something they’ve
> thought to look at before, although again there’s now an internal ticket to
> see about improving this.  For your round-tripping, I guess coming up with
> some name-generation system for anonymous types would have to do, although
> whether you can easily leave enough breadcrumbs to walk back from the
> template parameter type to the type-of-x seems like a question.
>

Yeah, not sure.


> Sorry I can’t provide any cleverness here.
>

No worries at all - glad to know I've probably not missed anything
game-changing for these cases, at least.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211228/9bf1e3b7/attachment-0001.html>