llvm dev - Aug 2021 - DWARF: Preferred names in templates

Context: https://reviews.llvm.org/D91311

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/20210808/519abccc/attachment.html>

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>

> On Aug 8, 2021, at 3:40 PM, David Blaikie via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Context: https://reviews.llvm.org/D91311
<https://reviews.llvm.org/D91311>
> 
> 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?
I agree that it seems like the solution is to not use preferred names for debug
info.

David and I chatted offline and he was able to come up with a scenario that
simulates the mixed debug info case where one compiler support preferred name
and the other does not and indeed LLDB has problems in this case. From what I
can tell this is because we are using the DW_AT_name from the parent, we
don't attempt to reconstruct the template parameters from the children's
DW_TAG_template_type_parameter.

Besides the fact that LLDB does not handle the mixed case well, it just seems
more desirable to have consistent naming.
> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210811/f81381f0/attachment.html>