<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 11, 2021 at 4:14 PM Shafik Yaghmour <<a href="mailto:syaghmour@apple.com">syaghmour@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Aug 8, 2021, at 3:40 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">Context: <a href="https://reviews.llvm.org/D91311" target="_blank">https://reviews.llvm.org/D91311</a><br><br>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><br>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><br>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><br>So I think the only good solution here is to suppress use of preferred names when printing type names for debug info?<br></div></div></blockquote><div><br></div><div>I agree that it seems like the solution is to not use preferred names for debug info.<br><br>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><br>Besides the fact that LLDB does not handle the mixed case well, it just seems more desirable to have consistent naming.</div></div></div></blockquote><div><br>Yep, finally coming back to this - I've disabled the use of preferred names in debug info here: <a href="https://github.com/llvm/llvm-project/commit/2ff049b12ee3fb60581835a28bf9d0acc1723f23">https://github.com/llvm/llvm-project/commit/2ff049b12ee3fb60581835a28bf9d0acc1723f23</a><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><br></div><blockquote type="cite"><div><div dir="ltr"><br>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><br>Thoughts, feelings, perspectives?<br><br>- Dave</div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></blockquote></div></div>