[llvm-dev] DWARF: Preferred names in templates

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Sun Aug 8 15:40:12 PDT 2021


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>


More information about the llvm-dev mailing list