<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>19.12.2017 23:12, Greg Clayton wrote:<br>
</p>
<blockquote type="cite"
cite="mid:3D1A9841-55FD-4F7A-AC0C-E1D434B9E062@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Dec 19, 2017, at 12:33 PM, Anton Gorenkov
<<a href="mailto:xgsa@yandex.ru" class=""
moz-do-not-send="true">xgsa@yandex.ru</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Menlo-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">Tamas, Greg, thank you, I got
the idea how it should work without accelerator tables,
but I still cannot figure out how to use/update the
existing accelerator tables. So let me walk trough it once
again:</span><br style="font-family: Menlo-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class=""> 1. It is necessary to
perform lookup by mangled name (as all we initially have
is mangled "vtable for ClassName"-symbol).</span><br
style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class=""> 2. All the existing apple
accelerator tables (e.g. apple_types) have demangled and
unqualified names as a key.</span><br style="font-family:
Menlo-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class=""> 3. It is not always
possible to get the original demanled type name by the
mangled one (e.g. for templates parametrized with enums
the demangled one is Impl<(TagType)0> vs original
Impl<TagType::Tag1>, but there are more complex
cases).</span><br style="font-family: Menlo-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">Thus, I don't see how adding
DW_AT_linkage_name to vtable member of class (or even to
class itself) could help, as it still won't be possible to
resolve DIE by the mangled type name. However possible
solutions are:</span><br style="font-family:
Menlo-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class=""> 1. To generate a separate
accelerator table: mangled name for vtable member of a
class => DIE;</span><br style="font-family:
Menlo-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class=""> 2. Build index on startup
iterating through the apple_types and gather the map
mangled name => DIE;</span><br style="font-family:
Menlo-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<br style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">Greg, did you mean some of
these or something else?</span><br style="font-family:
Menlo-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
</div>
</blockquote>
<div><br class="">
</div>
I didn't realize that the mangled name differs in certain cases
and that it wouldn't suffice for a lookup. Can you give an
example of the name we try looking up versus what is actually in
the symbol table? <br>
</div>
</blockquote>
Case 1:<br>
<pre>enum class TagType : bool {
Tag1
};
struct I {
virtual ~I() = default;
};
template <TagType Tag>
struct Impl : public I {
private:
int v = 123;
};
int main(int argc, const char * argv[]) {
Impl<TagType::Tag1> impl;
I& i = impl;
return 0;
}
lldb demangles the name to Impl<(TagType)0> and it's "Impl<TagType::Tag1>" in DWARF generated by clang.
Case 2:
struct I
{
virtual ~I(){}
};
template <int Tag>
struct Impl : public I
{
int v = 123;
};
template <>
struct Impl<1+1+1> : public I // Note the expression used for this specialization
{
int v = 124;
};
template <class T>
struct TT {
I* i = new T();
};
int main(int argc, const char * argv[]) {
TT<Impl<3>> tt;
return 0; // [*]
}
lldb demangles name to "Impl<3>", whereas clang generates "Impl<1+1+1>" in DWARF.
</pre>
<blockquote type="cite"
cite="mid:3D1A9841-55FD-4F7A-AC0C-E1D434B9E062@gmail.com">
<div>IIUC right now we lookup the address of the first pointer
within a class if it is virtual and find the symbol name that
this corresponds to, and in the failing cases you have we don't
find anything in the DWARF that matches. Is that right?</div>
</blockquote>
Exactly, for the cases above and some others.<br>
<blockquote type="cite"
cite="mid:3D1A9841-55FD-4F7A-AC0C-E1D434B9E062@gmail.com">
<div>
<blockquote type="cite" class="">
<div class=""><br style="font-family: Menlo-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">Thanks,</span><br
style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">Anton.</span><br
style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<br style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px;" class="">
<span style="font-family: Menlo-Regular; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; float: none; display:
inline !important;" class="">19.12.2017 19:39, Greg
Clayton wrote:</span><br style="font-family:
Menlo-Regular; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class="">
<blockquote type="cite" style="font-family: Menlo-Regular;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px;" class="">I agree with
Tamas. The right way to do this it to add the
DW_AT_linkage_name to the class. Apple accelerator tables
have many different forms, but one is a mapping of type
name to exact DIE offset (in the __DWARF_ segment in the
__apple_types section). If the mangled name was added to
the class, then the apple accelerator tables would have
it. So when a lookup happens with these tables around, we
do a very quick hash lookup, and we find the exact DIE (or
DIEs) we need. Entries for classes in the Apple
accelerator tables have both the mangled and raw class
name as entries pointing to the same DIE since lookups
don't usually happen via mangled names. LLDB also knows
how to pull names apart and search correctly, so if
someone tries to lookup a type with "a::b::MyClass", we
will chop that up into "MyClass" and do a lookup on that.
We might get many many different "MyClass" results back
(a::c::MyClass, ::MyClass, b::MyClass), but then we cull
those down by making sure any matches have a matching decl
context of "a::b::". For mangled names, it is easy and
just a direct lookup.<br class="">
<br class="">
The apple accelerator tables are only enabled for Darwin
target, but there is nothing to say we couldn't enable
these for other targets in ELF files. It would be a quick
way to gauge the performance improvement that these
accelerator tables provide for linux. Currently linux will
completely index the DWARF, but it will load the DWARF,
index it, and unload the DWARF so we don't hog memory for
things we don't need loaded yet. We must manually index
the DWARF because the DWARF accelerator tables are really
not accelerator tables, they are random indexes of related
data (names in no particular order, addresses in or
particular order). These tables are also not complete so
no debugger can rely on them. For example
".debug_pubtypes" is for "public" types only.
".debug_pubnames" is a random name table with only public
functions (no static functions or functions in anonymous
namespaces). So the DWARF accelerator tables can't be used
by debuggers.<br class="">
<br class="">
There is now a modified version of the Apple accelerator
tables in the DWARF standard that can provide the same
data as the Apple versions, but I don't believe anyone has
added this support to any compilers yet. So for
simplicity, we can try things out with the Apple
accelerator tables and see how things go.<br class="">
<br class="">
Another solution involves using llvm-dsymutil, a DWARF
linker that is used on Apple platforms. It is a tool that
is normally run on executables where the DWARF is left in
the .o files and linked later into final DWARF files. This
tool also has a "--update" option that take a linked dSYM
file and updates the accelerator tables in case they
change over time, or in case an older version of
llvm-dsymutil didn't add everything that was needed to the
tables due to a bug. So another way we can try this out is
to modify the llvm-dsymutil to work with ELF files and
have it generate and add the Apple accelerator tables to
the ELF files. This is nice because it allows us to use
DWARF that is generated by any compiler (no need for the
compiler to support making the accelerator tables). This
would a great way to try out the accelerator tables
without requiring compiler changes.<br class="">
<br class="">
The short term solution is to validate that the Apple
accelerator tables work and do speed debugging up by a
large amount. The long term solution is to have clang
start emitting the new DWARF accelerator tables and modify
LLDB to support and use those tables.<br class="">
<br class="">
Let me know if there are any questions on any of this.<br
class="">
<br class="">
Greg Clayton<br class="">
<br class="">
<blockquote type="cite" class="">On Dec 19, 2017, at 5:35
AM, Tamas Berghammer via lldb-dev <<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">lldb-dev@lists.llvm.org</a><span
class="Apple-converted-space"> </span><<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">mailto:lldb-dev@lists.llvm.org</a>>>
wrote:<br class="">
<br class="">
Hi,<br class="">
<br class="">
I thought most compiler still emits
DW_AT_MIPS_linkage_name instead of the standard
DW_AT_linkage_name but I agree that if we can we should
use the standard one.<br class="">
<br class="">
Regarding performance we have 2 different scenarios. On
Apple platforms we have the apple accelerator tables to
improve load time (might work on FreeBsd as well) while
on other platforms we Index the DWARF data
(DWARFCompileUnit::Index) to effectively generate
accelerator tables in memory what is a faster process
then fully parsing the DWARF (currently we only parse
function DIEs and we don't build the clang types). I
think an ideal solution would be to have the vtable name
stored in DWARF so the DWARF data is standalone and then
have some accelerator tables to be able to do fast
lookup from mangled symbol name to DIE offset. I am not
too familiar with the apple accelerator tables but if we
have anything what maps from mangled name to DIE offset
then we can add a few entry to it to map from mangled
vtable name to type DIE or vtable DIE.<br class="">
<br class="">
Tamas<br class="">
<br class="">
On Mon, Dec 18, 2017 at 9:02 PM xgsa <<a
href="mailto:xgsa@yandex.ru" class=""
moz-do-not-send="true">xgsa@yandex.ru</a><span
class="Apple-converted-space"> </span><<a
href="mailto:xgsa@yandex.ru" class=""
moz-do-not-send="true">mailto:xgsa@yandex.ru</a>>>
wrote:<br class="">
<br class="">
Hi Tamas,<br class="">
First, why DW_AT_MIPS_linkage_name, but not just<br
class="">
DW_AT_linkage_name? The later is standartized and
currently<br class="">
generated by clang at least on x64.<br class="">
Second, this doesn't help to solve the issue, because
this will<br class="">
require parsing all the DWARF types during startup to
build a map<br class="">
that breaks DWARF lazy load, performed by lldb. Or am
I missing<br class="">
something?<br class="">
Thanks,<br class="">
Anton.<br class="">
18.12.2017, 22:59, "Tamas Berghammer" <<a
href="mailto:tberghammer@google.com" class=""
moz-do-not-send="true">tberghammer@google.com</a><br
class="">
<<a href="mailto:tberghammer@google.com" class=""
moz-do-not-send="true">mailto:tberghammer@google.com</a>>>:<br
class="">
<blockquote type="cite" class=""><br class="">
Hi Anton and Jim,<br class="">
<br class="">
What do you think about storing the mangled type
name or the<br class="">
mangled vtable symbol name somewhere in DWARF in
the<br class="">
DW_AT_MIPS_linkage_name attribute? We are already
doing it for<br class="">
the mangled names of functions so extending it to
types<br class="">
shouldn't be too controversial.<br class="">
<br class="">
Tamas<br class="">
<br class="">
On Mon, 18 Dec 2017, 17:29 xgsa via lldb-dev,<br
class="">
<<a href="mailto:lldb-dev@lists.llvm.org"
class="" moz-do-not-send="true">lldb-dev@lists.llvm.org</a><span
class="Apple-converted-space"> </span><<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">mailto:lldb-dev@lists.llvm.org</a>>>
wrote:<br class="">
<br class="">
Thank you for clarification, Jim, you are
right, I<br class="">
misunderstood a little bit what lldb actually
does.<br class="">
<br class="">
It is not that the compiler can't be fixed,
it's about the<br class="">
fact that relying on correspondence of mangled
and demangled<br class="">
forms are not reliable enough, so we are
looking for more<br class="">
robust alternatives. Moreover, I am not sure
that such fuzzy<br class="">
matching could be done just basing on class
name, so it will<br class="">
require reading more DIEs. Taking into account
that, for<br class="">
instance, in our project there are quite many
such types, it<br class="">
could noticeable slow down the debugger.<br
class="">
<br class="">
Thus, I'd like to mention one more alternative
and get your<br class="">
feedback, if possible. Actually, what is
necessary is the<br class="">
correspondence of mangled and demangled vtable
symbol.<br class="">
Possibly, it worth preparing a separate section
during<br class="">
compilation (like e.g. apple_types), which
would store this<br class="">
correspondence? It will work fast and be more
reliable than<br class="">
the current approach, but certainly, will
increase debug<br class="">
info size (however, cannot estimate which exact
increase<br class="">
will be, e.g. in persent).<br class="">
<br class="">
What do you think? Which solution is
preferable?<br class="">
<br class="">
Thanks,<br class="">
Anton.<br class="">
<br class="">
15.12.2017, 23:34, "Jim Ingham" <<a
href="mailto:jingham@apple.com" class=""
moz-do-not-send="true">jingham@apple.com</a><br
class="">
<<a href="mailto:jingham@apple.com" class=""
moz-do-not-send="true">mailto:jingham@apple.com</a>>>:<br
class="">
> First off, just a technical point. lldb
doesn't use RTTI<br class="">
to find dynamic types, and in fact works for
projects like<br class="">
lldb & clang that turn off RTTI. It just
uses the fact that<br class="">
the vtable symbol for an object demangles to:<br
class="">
><br class="">
> vtable for CLASSNAME<br class="">
><br class="">
> That's not terribly important, but I just
wanted to make<br class="">
sure people didn't think lldb was doing
something fancy with<br class="">
RTTI... Note, gdb does (or at least used to do)
dynamic<br class="">
detection the same way.<br class="">
><br class="">
> If the compiler can't be fixed, then it
seems like your<br class="">
solution [2] is what we'll have to try.<br
class="">
><br class="">
> As it works now, we get the CLASSNAME from
the vtable<br class="">
symbol and look it up in the the list of types.
That is<br class="">
pretty quick because the type names are
indexed, so we can<br class="">
find it with a quick search in the index.
Changing this over<br class="">
to a method where we do some additional string
matching<br class="">
rather than just using the table's hashing is
going to be a<br class="">
fair bit slower because you have to run over
EVERY type<br class="">
name. But this might not be that bad. You would
first look<br class="">
it up by exact CLASSNAME and only fall back on
your fuzzy<br class="">
match if this fails, so most dynamic type
lookups won't see<br class="">
any slowdown. And if you know the cases where
you get into<br class="">
this problem you can probably further restrict
when you need<br class="">
to do this work so you don't suffer this
penalty for every<br class="">
lookup where we don't have debug info for the
dynamic type.<br class="">
And you could keep a side-table of mangled-name
-> DWARF<br class="">
name, and maybe a black-list for unfound names,
so you only<br class="">
have to do this once.<br class="">
><br class="">
> This estimation is based on the assumption
that you can do<br class="">
your work just on the type names, without
having to get more<br class="">
type information out of the DWARF for each
candidate match.<br class="">
A solution that relies on realizing every class
in lldb so<br class="">
you can get more information out of the type
information to<br class="">
help with the match will defeat all our
attempts at lazy<br class="">
DWARF reading. This can cause quite long delays
in big<br class="">
programs. So I would be much more worried about
a solution<br class="">
that requires this kind of work. Again, if you
can reject<br class="">
most potential candidates by looking at the
name, and only<br class="">
have to realize a few likely types, the
approach might not<br class="">
be that slow.<br class="">
><br class="">
> Jim<br class="">
><br class="">
>> On Dec 15, 2017, at 7:11 AM, xgsa via
lldb-dev<br class="">
<<a href="mailto:lldb-dev@lists.llvm.org"
class="" moz-do-not-send="true">lldb-dev@lists.llvm.org</a><span
class="Apple-converted-space"> </span><<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">mailto:lldb-dev@lists.llvm.org</a>>><br
class="">
wrote:<br class="">
>><br class="">
>> Sorry, I probably shouldn't have used
HTML for that<br class="">
message. Converted to plain text.<br class="">
>><br class="">
>> -------- Original message --------<br
class="">
>> 15.12.2017, 18:01, "xgsa" <<a
href="mailto:xgsa@yandex.ru" class=""
moz-do-not-send="true">xgsa@yandex.ru</a><br
class="">
<<a href="mailto:xgsa@yandex.ru" class=""
moz-do-not-send="true">mailto:xgsa@yandex.ru</a>>>:<br
class="">
>><br class="">
>> Hi,<br class="">
>><br class="">
>> I am working on issue that in C++
program for some<br class="">
complex cases with templates showing dynamic
type based on<br class="">
RTTI in lldb doesn't work properly. Consider
the following<br class="">
example:<br class="">
>> enum class TagType : bool<br class="">
>> {<br class="">
>> Tag1<br class="">
>> };<br class="">
>><br class="">
>> struct I<br class="">
>> {<br class="">
>> virtual ~I() = default;<br
class="">
>> };<br class="">
>><br class="">
>> template <TagType Tag><br
class="">
>> struct Impl : public I<br class="">
>> {<br class="">
>> private:<br class="">
>> int v = 123;<br class="">
>> };<br class="">
>><br class="">
>> int main(int argc, const char *
argv[]) {<br class="">
>> Impl<TagType::Tag1> impl;<br
class="">
>> I& i = impl;<br class="">
>> return 0;<br class="">
>> }<br class="">
>><br class="">
>> For this example clang generates type
name<br class="">
"Impl<TagType::Tag1>" in DWARF and
"__ZTS4ImplIL7TagType0EE"<br class="">
when mangling symbols (which lldb demangles to<br
class="">
Impl<(TagType)0>). Thus when in<br
class="">
ItaniumABILanguageRuntime::GetTypeInfoFromVTableAddress()<br
class="">
lldb tries to resolve the type, it is unable to
find it.<br class="">
More cases and the detailed description why
lldb fails here<br class="">
can be found in this clang review, which tries
to fix this<br class="">
in clang [1].<br class="">
>><br class="">
>> However, during the discussion around
this review [2],<br class="">
it was pointed out that DWARF names are
expected to be close<br class="">
to sources, which clang does perfectly, whereas
mangling<br class="">
algorithm is strictly defined. Thus matching
them on<br class="">
equality could sometimes fail. The suggested
idea in [2] was<br class="">
to implement more semantically aware matching.
There is<br class="">
enough information in the DWARF to semantically
match<br class="">
"Impl<(TagType)0>)" with
"Impl<TagType::Tag1>", as enum<br class="">
TagType is in the DWARF, and the enumerator
Tag1 is present<br class="">
with its value 0. I have some concerns about
the performance<br class="">
of such solution, but I'd like to know your
opinion about<br class="">
this idea in general. In case it is approved,
I'm going to<br class="">
work on implementing it.<br class="">
>><br class="">
>> So what do you think about type names
inequality and the<br class="">
suggested solution?<br class="">
><br class="">
>> [1] -<span
class="Apple-converted-space"> </span><a
href="https://reviews.llvm.org/D39622" class=""
moz-do-not-send="true">https://reviews.llvm.org/D39622</a><br
class="">
>> [2] -<br class="">
<a
href="http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171211/212859.html"
class="" moz-do-not-send="true">http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171211/212859.html</a><br
class="">
>><br class="">
>> Thank you,<br class="">
>> Anton.<br class="">
>>
_______________________________________________<br
class="">
>> lldb-dev mailing list<br class="">
>><span class="Apple-converted-space"> </span><a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">lldb-dev@lists.llvm.org</a><span
class="Apple-converted-space"> </span><<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">mailto:lldb-dev@lists.llvm.org</a>><br
class="">
>><span class="Apple-converted-space"> </span><a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" class=""
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br
class="">
_______________________________________________<br
class="">
lldb-dev mailing list<br class="">
<a href="mailto:lldb-dev@lists.llvm.org"
class="" moz-do-not-send="true">lldb-dev@lists.llvm.org</a><span
class="Apple-converted-space"> </span><<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">mailto:lldb-dev@lists.llvm.org</a>><br
class="">
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev"
class="" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br
class="">
<br class="">
</blockquote>
_______________________________________________<br
class="">
lldb-dev mailing list<br class="">
<a href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">lldb-dev@lists.llvm.org</a><span
class="Apple-converted-space"> </span><<a
href="mailto:lldb-dev@lists.llvm.org" class=""
moz-do-not-send="true">mailto:lldb-dev@lists.llvm.org</a>><br
class="">
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev"
class="" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a></blockquote>
</blockquote>
</div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
</body>
</html>