[llvm-dev] DWARF: Preferred names in templates

[via llvm-dev]

Sony already has a private patch to not desugar type names in the DW_TAG_template_type_parameter name.  IIRC we were finding that e.g. enums decayed to the underlying integer, which caused loss of useful information.
It kind of feels like D91311 is heading in a similar direction, and really ought to be using the preferred name in the parameter DIEs as well as the parent, for consistency.
Full disclosure, our debugger throws away the <template-parameters> in the parent name and reconstructs it from the parameter DIEs.  So, what the compiler emits in the parent name is not interesting to our debugger.  (And wasn’t there a suggestion at some point to eliminate the <template-parameters> in the parent anyway?  Because they could lead to an explosion of really long strings in the debug info, and those strings aren’t particularly user-friendly in the first place.)
--paulr

From: David Blaikie <dblaikie at gmail.com>
Sent: Sunday, August 8, 2021 6:40 PM
To: Adrian Prantl <aprantl at apple.com>; Jonas Devlieghere <jdevlieghere at apple.com>; Robinson, Paul <paul.robinson at sony.com>; llvm-dev <llvm-dev at lists.llvm.org>; Reid Kleckner <rnk at google.com>
Subject: DWARF: Preferred names in templates

Context: https://reviews.llvm.org/D91311<https://urldefense.com/v3/__https:/reviews.llvm.org/D91311__;!!JmoZiZGBv3RvKRSx!pJGuSYSXSZoUDceMyw0Nw0ln_aNgMLvUQXTNQ54R6hcXxGnb-_GXpIbn3-XyMLZ7ZQ$>

So, this preferred name feature is designed to print names in a more user-centric way (eg: "std::vector<std::string, ...>" instead of "std::vector<std::basic_string<char, ...>, ...>".

But this causes some divergence in the DWARF - the textual string says std::string, but the DW_TAG_template_type_parameter says std::basic_string<char...

This isn't fundamentally problematic, kind of - there's a bunch of ways the full string name of a template won't match perfectly between producers and so consumers basically have to do some structural equivalence testing so far as I know. Though I'm not sure exactly how much - they could do it by normalizing the string (with GCC and LLVM's default debug info don't include structural descriptions of template parameters on template declarations - so consumers would have to do string normalization, rather than discarding the string argument representation and relying solely on the structural representation) in which case only a very advanced normalization that parsed std::string, did a lookup, resolved through typedefs and alias templates and then used the resulting string would succeed here. I haven't tested gdb or lldb to see if/how they cope with this situation - but I would assume it's not good.

So I think the only good solution here is to suppress use of preferred names when printing type names for debug info?

It might be nice to have use of preferred names (& maybe take it further - I have a prototype patch - and use the preferred names/types in the structural representation as well (which presumably would break mixed clang/gcc debug info with most consumers, I'd imagine - maybe it'd fall out OK for lldb when building ASTs)) under a flag? If you're building the codebase with one compiler and/or you just want to do more experimentation with the feature? Not sure it's worth it, but I think I have some reasonable attempt at this... (there's one issue around cases of template declarations not carrying preferred names - discussed on the review itself)

Thoughts, feelings, perspectives?

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210809/031eaa87/attachment.html>