<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 8, 2021, at 3:40 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Context: <a href="https://reviews.llvm.org/D91311" class="">https://reviews.llvm.org/D91311</a><br class=""><br class="">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, ...>, ...>".<br class=""><br class="">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... <br class=""><br class="">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.<br class=""><br class="">So I think the only good solution here is to suppress use of preferred names when printing type names for debug info?<br class=""></div></div></blockquote><div><br class=""></div><div>I agree that it seems like the solution is to not use preferred names for debug info.<br class=""><br class="">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.<br class=""><br class="">Besides the fact that LLDB does not handle the mixed case well, it just seems more desirable to have consistent naming.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="">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)<br class=""><br class="">Thoughts, feelings, perspectives?<br class=""><br class="">- Dave</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>