[llvm-dev] DWARF: Preferred names in templates (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 9 12:16:54 PDT 2021

On Mon, Aug 9, 2021 at 5:35 AM <paul.robinson at sony.com> wrote:

Sony already has a private patch to not desugar type names in the DWTAGtemplatetypeparameter name. IIRC we were finding that e.g. enums decayed to the underlying integer, which caused loss of useful information.

Ah, hmm. If you've got any particular reproductions I'd love to take a look at something like that.

I guess you don't have any compatibility needs - between DWARF produced by different producers (old Clang + new Clang, GCC + Clang, etc)? Otherwise these differences, I would think, would make matching entities difficult? Or do you have code in the consumers to look through sugar (typedefs, alias templates, etc) when doing structural equivalence matching between entities described in different CUs? Some other solutions or reason that issue doesn't come up in your context?

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.

Ish - but it's one thing for diagnostics to do this, it's a bit trickier for DWARF to do it. I agree we should resolve the consistency, but due to the need for consistency with other compilers (& even just older clang) I suspect the thing to do is to avoid the preferred name - so that structural equivalence can be tested without needing to know which types are transparent for the purpose of such equivalence, and which are not?

Full disclosure, our debugger throws away the 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.

Yeah, I suspect consumers have to do something like this - though I guess GDB and LLDB do some kind of canonicalization of the string representation (owing to the lack of structural representation on declarations).

(And wasn’t there a suggestion at some point to eliminate the 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.)

Yeah, that's where this came up - I've developed a patch for clang that allows choosing one of 3 options (1) the way things are now, (2) strips certain template name strings of their template parameter lists or (3) instead of stripping those lists from those names, instead adds a prefix to flag the name as one that /should/ be able to be stripped. Then I have a patch to llvm-dwarfdump --verify that, upon detecting that prefix attempts to rebuild the full name and checks that it matches. So I found this mismatch when running this checking mode over clang build inside google, which uses libc++ (I've already got this checking mode clear on clang and llvm-dwarfdump build in my open source build (which happens not to use libc++), which is nice to know - modulo one issue with type suffixes on non-type template parameters, which are applied only in certain cases, it's hard/impossible to detect those certain cases in DWARF, so I always add the suffixes and have a local patch to clang to always put them on the decorated name to get past these cases/not have them noisy-up the results)

--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!pJGuSYSXSZoUDceMyw0Nw0lnaNgMLvUQXTNQ54R6hcXxGnb-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::basicstring<char, ...>, ...>". But this causes some divergence in the DWARF - the textual string says std::string, but the DWTAGtemplatetypeparameter says _std::basicstring<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/8be47579/attachment.html>

More information about the llvm-dev mailing list