<div dir="ltr">Not much - I've put them on this part of the thread specifically to raise attention.<br><br>If it doesn't get visibility here, maybe a cfe-dev thread would be good.<br><br><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 19, 2017 at 1:33 PM Anton Gorenkov <<a href="mailto:xgsa@yandex.ru">xgsa@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Sorry, I am quite new to the process. It seems, Adrian and Paul
are in the reviewers/subscribers list to the original review
(<a class="m_-7675014215528886461moz-txt-link-freetext" href="https://reviews.llvm.org/D39622" target="_blank">https://reviews.llvm.org/D39622</a>). Should I do something else?</p></div><div text="#000000" bgcolor="#FFFFFF">
<div class="m_-7675014215528886461moz-cite-prefix">19.12.2017 23:06, David Blaikie wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Yep, could be worth having a conversation with the
GDB folks and/or at least poke the other LLVM debug info folks
(Adrian and Paul - Paul's pretty interesting since he works
with/on another (not LLDB nor GDB) debugger which would have to
think about this functionality/feature/issue/data/limitation)</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Dec 19, 2017 at 1:04 PM Anton Gorenkov
<<a href="mailto:xgsa@yandex.ru" target="_blank">xgsa@yandex.ru</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There was a
discussion in lldb-dev mailing list on this topic and I<br>
suppose a reliable solution was suggested [1]. It is to
generate<br>
DW_AT_linkage_name for vtable DIE of a class and provide an
additional<br>
accelerator table. I am going to try to implement this
approach (it will<br>
require some work on both clang and lldb sides), but I'd like
also to<br>
understand if I should discard or complete the current patch.
Certainly,<br>
I'd prefer to complete it if it could be applied (I suppose,
at least<br>
tests should be added), because even with long term solution
implemented<br>
in clang/lldb, gdb still won't resolve dynamic types properly
for the<br>
described cases.<br>
<br>
[1] - <a href="http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/lldb-dev/2017-December/013048.html</a><br>
<br>
15.12.2017 21:25, David Blaikie via cfe-commits wrote:<br>
><br>
><br>
> On Fri, Dec 15, 2017 at 8:09 AM xgsa <<a href="mailto:xgsa@yandex.ua" target="_blank">xgsa@yandex.ua</a><br>
> <mailto:<a href="mailto:xgsa@yandex.ua" target="_blank">xgsa@yandex.ua</a>>>
wrote:<br>
><br>
> David, thank you for the detailed answer and corner
cases.<br>
> Just to clarify: everywhere in my mail where I
mentioned<br>
> "debugger", I meant LLDB, but not GDB (except, where
I mentioned<br>
> GDB explicitly). Currently, I have no plans to work
on GDB,<br>
> however I would like to make the clang+LLDB pair
working in such<br>
> cases.<br>
><br>
><br>
> *nod* My concern is making sure, if possible, we figure
out a design<br>
> that seems viable long-term/in general. (& if we
figure out what that<br>
> design is, but decide it's not achievable immediately, we
can make<br>
> deliberate tradeoffs, document the long term goal &
what the short<br>
> term solutions cost relative to that goal, etc)<br>
><br>
> Thus, I have described your idea in the lldb-dev
mailing list [1].<br>
> Still, I have some concerns about the performance of
such<br>
> semantically aware matching. Currently, with
acceleration tables<br>
> (e.g. apple_types etc) the matching is as fast as
lookup in hash<br>
> map and hash map is loade almost without
postprocessing.<br>
> Semantically aware matching will require either
processing during<br>
> statup or almost linear lookup.<br>
><br>
><br>
> Yep, I agree - that seems like a reasonable concern. I
wonder whether<br>
> it'd be reasonable to put accelerator table entries
containing the<br>
> base name of the template to ease such lookup?<br>
><br>
> Still, should this topic be raised in cde-dev or are
all the<br>
> interested people already here?<br>
><br>
><br>
> Yeah, might be worth moving this to a thread there.
Though we probably<br>
> have all the right people here, it's a better spot for
the<br>
> conversation even for spectators, history (finding this
later when we<br>
> have similar questions, etc), etc.<br>
><br>
> [1] -<br>
> <a href="http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/lldb-dev/2017-December/013038.html</a><br>
> 14.12.2017, 22:40, "David Blaikie" <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a><br>
> <mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>>:<br>
>> On Thu, Dec 14, 2017 at 2:21 AM Anton via
Phabricator<br>
>> <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>
<mailto:<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>>>
wrote:<br>
>><br>
>> xgsa added a comment.<br>
>><br>
>> In <a href="https://reviews.llvm.org/D39622#954585" rel="noreferrer" target="_blank">https://reviews.llvm.org/D39622#954585</a>,
@probinson wrote:<br>
>><br>
>> > Philosophically, mangled names and DWARF
information serve<br>
>> different purposes, and I don't think you
will find one true<br>
>> solution where both of them can yield the
same name that<br>
>> everyone will be happy with. Mangled names
exist to provide<br>
>> unique and reproducible identifiers for the
"same" entity<br>
>> across compilation units. They are carefully
specified (for<br>
>> example) to allow a linker to associate a
reference in one<br>
>> object file to a definition in a different
object file, and<br>
>> be guaranteed that the association is
correct. A demangled<br>
>> name is a necessarily context-free
translation of the mangled<br>
>> name into something that has a closer
relationship to how a<br>
>> human would think of or write the name of the
thing, but<br>
>> isn't necessarily the only way to write the
name of the thing.<br>
>> ><br>
>> > DWARF names are (deliberately not
carefully specified)<br>
>> strings that ought to bear some relationship
to how source<br>
>> code would name the thing, but you probably
don't want to<br>
>> attach semantic significance to those names.
This is rather<br>
>> emphatically true for names containing
template parameters. <br>
>> Typedefs (and their recent offspring, 'using'
aliases) are<br>
>> your sworn enemy here. Enums, as you have
found, are also a<br>
>> problem.<br>
>> ><br>
>> > Basically, the type of an entity does
not have a unique<br>
>> name, and trying to coerce different
representations of the<br>
>> type into having the same unique name is a
losing battle.<br>
>><br>
>><br>
>> I'm actually going back and forth on this ^. It
seems to me,<br>
>> regardless of mangled names, etc, it'd be good if
LLVM used the<br>
>> same name for a type in DWARF across different
translation units.<br>
>> And, to a large extent, we do (the case of
typedefs in template<br>
>> parameters doesn't seem to present a problem for
the current<br>
>> implementation - the underlying type is used),
enums being one<br>
>> place where we don't - and we don't actually make
it that much<br>
>> closer to the source/based on what the user
wrote.<br>
>><br>
>> Even if the user had: "enum X { Y = 0, Z = 0; }
... template<enum<br>
>> X> struct foo; ... foo<Z>" LLVM still
describes that type as<br>
>> "foo<X::Y>". Also if you have "enum X: int;
... foo<(X)0>" you<br>
>> get "foo<0>" whereas in another translation
unit with a<br>
>> definition of X you'd get "foo<X::Y>".<br>
>><br>
>> So for consistency there, I kind of think maybe a
change like<br>
>> this isn't bad.<br>
>><br>
>> But of course the specific way a template name is
written may<br>
>> easily still vary between compilers, so relying
on it being<br>
>> exactly the same might not be a great idea
anyway...<br>
>><br>
>> Thank you for clarification, Paul!
Nevertheless, I suppose,<br>
>> showing actual type of a dynamic variable is
very important<br>
>> for the projects, where RTTI is used.
Moreover, it works<br>
>> properly in gcc+gdb pair, so I am extremely
interested in<br>
>> fixing it in clang+lldb.<br>
>><br>
>> I understand that the suggested solution
possibly does not<br>
>> cover all the cases, but it improves the
situation and<br>
>> actually covers all the cases found by me (I
have just<br>
>> rechecked -- typedefs/usings seems to work
fine when<br>
>> displaying the real type of variable). If
more cases are<br>
>> found in future, they could be fixed
similarly too. Moreover,<br>
>> the debuggers already rely on the fact that
the type name<br>
>> looks the same in RTTI and DWARF, and I
suppose they have no<br>
>> choice, because there is no other source of
information for<br>
>> them (or am I missing something?).<br>
>><br>
>><br>
>> I think they would have a choice, actually -
let's walk through<br>
>> it...<br>
>><br>
>> It sounds like you're thinking of two other
possibilities:<br>
>><br>
>> 1) "I suppose, we cannot extend RTTI with the
debug type name (is<br>
>> it correct?)" - yeah, that's probably correct,
extending the RTTI<br>
>> format probably isn't desirable and we'd still
need a<br>
>> singular/canonical DWARF name which we don't seem
to have (& the<br>
>> RTTI might go in another object file that may not
have debug<br>
>> info, or debug info generated by a different
compiler with a<br>
>> different type printing format, etc... )<br>
>><br>
>> 2) Extending DWARF to include the mangled name<br>
>> Sort of possible, DW_AT_linkage_name on a
DW_AT_class could be<br>
>> used for this just fine - no DWARF extension
required.<br>
>><br>
>> But an alternative would be to have debuggers use
a more<br>
>> semantically aware matching here. The debugger
does have enough<br>
>> information in the DWARF to semantically match
"foo<(X)0>" with<br>
>> "foo<X::Y>". enum X is in the DWARF, and
the enumerator Y is<br>
>> present with its value 0.<br>
>><br>
>> Another case of Clang's DWARF type printing
differing from a<br>
>> common demangling, is an unsigned parameter.
template<unsigned><br>
>> foo; foo<0> - common demangling for this is
"foo<0u>" but Clang<br>
>> will happily render the type as "foo<0>" -
this one seems less<br>
>> easy to justify changing than the enum case (the
enum case, given<br>
>> the declared-but-not-defined enum example, seems
more compelling<br>
>> to try to have clang give a consistent name to
the type (which,<br>
>> while not complete (differing compilers could
still use different<br>
>> printings), seems somewhat desirable)) because
it's at least<br>
>> self-consistent.<br>
>><br>
>> Again, in this case, a debugger could handle
this.<br>
>><br>
>> All that said, GDB is the elephant in the room
and I imagine<br>
>> might have no interest in adopting a more complex
name<br>
>> lookup/comparison strategy & we might just
have to bow to their<br>
>> demangling printing and naming scheme... but
might be worth<br>
>> asking GDB folks first? Not sure.<br>
>><br>
>> Another advantage of this solution is that it
doesn't require<br>
>> any format extension and will probably work
out of the box in<br>
>> gdb and other debuggers. Moreover, I have
just rechecked, gcc<br>
>> generates exactly the same type names in
DWARF for examples<br>
>> in the description.<br>
>><br>
>> On the other hand, I understand the idea you
have described,<br>
>> but I am not sure how to implement this
lookup in another<br>
>> way. I suppose, we cannot extend RTTI with
the debug type<br>
>> name (is it correct?). Thus, the only way I
see is to add<br>
>> additional information about the mangled type
name into<br>
>> DWARF. It could be either a separate section
(like<br>
>> apple_types) or a special node for<br>
>> TAG_structure_type/TAG_class_type, which
should be indexed<br>
>> into map for fast lookup. Anyway, this will
be an extension<br>
>> to DWARF and will require special support in
a debugger.<br>
>> Furthermore, such solution will be much
complicated (still I<br>
>> don't mind working on it).<br>
>><br>
>> So what do you think? Is the suggested
solution not full or<br>
>> not acceptable? Do you have other ideas how
this feature<br>
>> should be implemented?<br>
>><br>
>> P.S. Should this question be raised in
mailing list? And if<br>
>> yes, actually, in which ones (clang or
lldb?), because it<br>
>> seems related to both clang and lldb?<br>
>><br>
>><br>
>> <a href="https://reviews.llvm.org/D39622" rel="noreferrer" target="_blank">https://reviews.llvm.org/D39622</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</div></blockquote></div></div>