[cfe-dev] DebugInfo: Template names

via cfe-dev cfe-dev at lists.llvm.org
Thu Dec 9 09:52:39 PST 2021


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

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

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

Sorry I can’t provide any cleverness here.
--paulr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211209/2dd345e1/attachment-0001.html>


More information about the cfe-dev mailing list