On Thu, Dec 14, 2017 at 2:21 AM Anton via Phabricator < revi...@reviews.llvm.org> wrote:
> xgsa added a comment. > > In https://reviews.llvm.org/D39622#954585, @probinson wrote: > > > Philosophically, mangled names and DWARF information serve different > purposes, and I don't think you will find one true solution where both of > them can yield the same name that everyone will be happy with. Mangled > names exist to provide unique and reproducible identifiers for the "same" > entity across compilation units. They are carefully specified (for > example) to allow a linker to associate a reference in one object file to a > definition in a different object file, and be guaranteed that the > association is correct. A demangled name is a necessarily context-free > translation of the mangled name into something that has a closer > relationship to how a human would think of or write the name of the thing, > but isn't necessarily the only way to write the name of the thing. > > > > DWARF names are (deliberately not carefully specified) strings that > ought to bear some relationship to how source code would name the thing, > but you probably don't want to attach semantic significance to those > names. This is rather emphatically true for names containing template > parameters. Typedefs (and their recent offspring, 'using' aliases) are > your sworn enemy here. Enums, as you have found, are also a problem. > > > > Basically, the type of an entity does not have a unique name, and trying > to coerce different representations of the type into having the same unique > name is a losing battle. > I'm actually going back and forth on this ^. It seems to me, regardless of mangled names, etc, it'd be good if LLVM used the same name for a type in DWARF across different translation units. And, to a large extent, we do (the case of typedefs in template parameters doesn't seem to present a problem for the current implementation - the underlying type is used), enums being one place where we don't - and we don't actually make it that much closer to the source/based on what the user wrote. Even if the user had: "enum X { Y = 0, Z = 0; } ... template<enum X> struct foo; ... foo<Z>" LLVM still describes that type as "foo<X::Y>". Also if you have "enum X: int; ... foo<(X)0>" you get "foo<0>" whereas in another translation unit with a definition of X you'd get "foo<X::Y>". So for consistency there, I kind of think maybe a change like this isn't bad. But of course the specific way a template name is written may easily still vary between compilers, so relying on it being exactly the same might not be a great idea anyway... > Thank you for clarification, Paul! Nevertheless, I suppose, showing actual > type of a dynamic variable is very important for the projects, where RTTI > is used. Moreover, it works properly in gcc+gdb pair, so I am extremely > interested in fixing it in clang+lldb. > > I understand that the suggested solution possibly does not cover all the > cases, but it improves the situation and actually covers all the cases > found by me (I have just rechecked -- typedefs/usings seems to work fine > when displaying the real type of variable). If more cases are found in > future, they could be fixed similarly too. Moreover, the debuggers already > rely on the fact that the type name looks the same in RTTI and DWARF, and I > suppose they have no choice, because there is no other source of > information for them (or am I missing something?). I think they would have a choice, actually - let's walk through it... It sounds like you're thinking of two other possibilities: 1) "I suppose, we cannot extend RTTI with the debug type name (is it correct?)" - yeah, that's probably correct, extending the RTTI format probably isn't desirable and we'd still need a singular/canonical DWARF name which we don't seem to have (& the RTTI might go in another object file that may not have debug info, or debug info generated by a different compiler with a different type printing format, etc... ) 2) Extending DWARF to include the mangled name Sort of possible, DW_AT_linkage_name on a DW_AT_class could be used for this just fine - no DWARF extension required. But an alternative would be to have debuggers use a more semantically aware matching here. The debugger does have enough information in the DWARF to semantically match "foo<(X)0>" with "foo<X::Y>". enum X is in the DWARF, and the enumerator Y is present with its value 0. Another case of Clang's DWARF type printing differing from a common demangling, is an unsigned parameter. template<unsigned> foo; foo<0> - common demangling for this is "foo<0u>" but Clang will happily render the type as "foo<0>" - this one seems less easy to justify changing than the enum case (the enum case, given the declared-but-not-defined enum example, seems more compelling to try to have clang give a consistent name to the type (which, while not complete (differing compilers could still use different printings), seems somewhat desirable)) because it's at least self-consistent. Again, in this case, a debugger could handle this. All that said, GDB is the elephant in the room and I imagine might have no interest in adopting a more complex name lookup/comparison strategy & we might just have to bow to their demangling printing and naming scheme... but might be worth asking GDB folks first? Not sure. > Another advantage of this solution is that it doesn't require any format > extension and will probably work out of the box in gdb and other debuggers. > Moreover, I have just rechecked, gcc generates exactly the same type names > in DWARF for examples in the description. > > On the other hand, I understand the idea you have described, but I am not > sure how to implement this lookup in another way. I suppose, we cannot > extend RTTI with the debug type name (is it correct?). Thus, the only way I > see is to add additional information about the mangled type name into > DWARF. It could be either a separate section (like apple_types) or a > special node for TAG_structure_type/TAG_class_type, which should be indexed > into map for fast lookup. Anyway, this will be an extension to DWARF and > will require special support in a debugger. Furthermore, such solution will > be much complicated (still I don't mind working on it). > > So what do you think? Is the suggested solution not full or not > acceptable? Do you have other ideas how this feature should be implemented? > > P.S. Should this question be raised in mailing list? And if yes, actually, > in which ones (clang or lldb?), because it seems related to both clang and > lldb? > > > https://reviews.llvm.org/D39622 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
