On Fri, Dec 15, 2017 at 8:09 AM xgsa <x...@yandex.ua> wrote: > David, thank you for the detailed answer and corner cases. > > Just to clarify: everywhere in my mail where I mentioned "debugger", I > meant LLDB, but not GDB (except, where I mentioned GDB explicitly). > Currently, I have no plans to work on GDB, however I would like to make the > clang+LLDB pair working in such cases. >
*nod* My concern is making sure, if possible, we figure out a design that seems viable long-term/in general. (& if we figure out what that design is, but decide it's not achievable immediately, we can make deliberate tradeoffs, document the long term goal & what the short term solutions cost relative to that goal, etc) > Thus, I have described your idea in the lldb-dev mailing list [1]. Still, > I have some concerns about the performance of such semantically aware > matching. Currently, with acceleration tables (e.g. apple_types etc) the > matching is as fast as lookup in hash map and hash map is loade almost > without postprocessing. Semantically aware matching will require either > processing during statup or almost linear lookup. > Yep, I agree - that seems like a reasonable concern. I wonder whether it'd be reasonable to put accelerator table entries containing the base name of the template to ease such lookup? > Still, should this topic be raised in cde-dev or are all the interested > people already here? > Yeah, might be worth moving this to a thread there. Though we probably have all the right people here, it's a better spot for the conversation even for spectators, history (finding this later when we have similar questions, etc), etc. > > [1] - http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html > > 14.12.2017, 22:40, "David Blaikie" <dblai...@gmail.com>: > > > 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
