llvm dev - Mar 2018 - Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

I don't understand how extra vtable ref DIE will help in case on
non-polymorphic classes. If you remove virtual destructor from example,
vtable won't be generated for class, but DWARF will still have incorrect
ambiguous names for types.
It will become a problem when you need to use debuginfo as a C++ runtime
reflection (I've already seen this in a couple of projects). Or when you
need to go back from LLVM IR to Clang AST (I've already encountered this
problem).

I wonder if  abi::__cxa_demangle guarantees unambigous names?  If so, then
I can just replace current incorrect names that Clang generates, with names
from demangler. In this case I don't even need to patch gdb, it will work
as is.

-Roman

2018-03-05 10:46 GMT-08:00 Daniel Berlin <dberlin at dberlin.org>:
>
>
> On Mon, Mar 5, 2018, 9:26 AM David Blaikie <dblaikie at gmail.com>
wrote:
>
>> On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at
dberlin.org> wrote:
>>
>>> On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie at
gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev
<
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> As you may know modern C++ debuggers (GDB and LLDB)
support dynamic
>>>>>> type identification for polymorphic objects, by
utilizing C++ RTTI.
>>>>>> Unfortunately this feature does not work with Clang and
GDB >= 7.x .
>>>>>> The last compiler that worked well was G++ 6.x
>>>>>>
>>>>>> I've asked about this issue both on GDB and LLDB
maillists.
>>>>>> Unfortunately it's hard or impossible to fix it on
debugger side.
>>>>>>
>>>>>
>>>>> Errr, i posited a solution on the gdb mailing list that i
haven't seen
>>>>> shot down so far, that doesn't require linkage names,
it only requires one
>>>>> new attribute that is a DW_FORM_ref, and very cheap.
>>>>>
>>>>
>>>> FWIW, for C++ at least, neither Clang nor GCC (6.3) produce any
DWARF
>>>> to describe the vtable itself (they describe the vtable pointer
inside the
>>>> struct, but not the constant vtable array) - so it'll be a
bit more than
>>>> one attribute, but the bytes describe the vtable (as a global
variable? Do
>>>> we give it a name? (if so, we're back to paying that cost))
first, then to
>>>> add the reference from that to the type.
>>>>
>>>
>>> Right, they produce a named symbol but not debug info.
>>>
>>> The only thing you need is a single DIE for that symbol, with a
single
>>> ref.
>>>
>>
>> When you say "a single DIE" what attributes are you picturing
that DIE
>> having? If it has a single attribute, a ref_addr to the type, that
doesn't
>> seem to provide anything useful. Presumably this DIE would need a
>> DW_AT_location with the address of the vtable (with a relocation to
resolve
>> that address, etc).
>>
>
> Location and concrete type it belongs to.  That's the minimum you
should
> need here.
> You don't need the name, though it doesn't hurt.
>
>
>> No name? No other identifying features? I don't think we've
ever really
>> produced DIEs like that, though it sounds OK to me.
>>
>>
>>>
>>> (IE they just need to be able to say "find me the DIE for this
address
>>> range", have it get to the vtable DIE, and get to the concrete
type die)
>>>
>>>
>>>>
>>>> & I'm not sure what Apple would do or anyone else that
has libraries
>>>> without debug info shipped & users have to debug them (this
is what broke
>>>> -fno-standalone-debug for Apple - their driver API which ships
without
>>>> debug info of its own, has strong vtables in it).
>>>>
>>>
>>> I'm confused.
>>> This already seems to have  has the same issue?
>>> Just because it uses one linker symbol, it still requires full
debug
>>> info to print the type anyway.
>>>
>> So if it's gone, nothing changes.
>>>
>>
>> Sorry, I don't quite understand your comment here - could you
explain it
>> in more detail - the steps/issues you're seeing?
>>
>
> I think we are starting from different positions here, so let me add a few
> pieces of data and see how it helps.
>
> Let's assume the below is true and it won't work on OSX as
described (i'm
> certainly in no place to disagree).
>
> Some data points:
>
> 1. LLDB works just fine on Darwin (it appears to do the same thing we did
> in gdb, staring at source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/
> ItaniumABILanguageRuntime.cpp)
>
> 2. GDB does not work on Darwin at all for any real debugging right now
> (You can't debug llvm with it, for example).  There are barely working
> versions here and there.  The startup time to debug an "opt"
binary from
> llvm is well over 2 minutes alone to get to a prompt just from typing
"gdb
> bin/opt". It requires 4 gigs of ram.  It usually fails to print most
> symbols/types/crashes calling functions, blah blah blah.
> You can't even quit most of the time without hitting an assert.
> (gdb) q
> thread.c:93: internal-error: struct thread_info *inferior_thread():
> Assertion `tp' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y
>
>
>
> 3. On every platform, GDB will have to continue to use what it does now as
> a fallback anyway, as all existing binaries will not be rebuilt.
> 4. Ditto LLDB
>
> So for GDB, it doesn't really matter whether it breaks OSX, to start.
> Even if it did, it will still work as well or as not well as it has in the
> past :)
>
> LLDB works, and should work as well as it did with or without this as well.
>
> Given all that: No matter what we do, LLDB and GDB will continue to work
> exactly as well or as broken as they have before on OSX. Nothing will
> change.
>
> So i wouldn't call it broken, i'd call it, at worst, inapplicable
to
> certain situations on OSX, and triggering a fallback :)
>
>
>
>> I'll try to do the same:
>> Currently the DWARF type information (the actual DW_TAG_class_type DIE
>> with the full definition of the class - its members, etc) on OSX goes
>> everywhere the type is used (rather than only in the object files where
the
>> vtable is defined) to ensure that types defined in objects built
without
>> debug info, but used in objects built with debug info can still be
>> debugged. (whereas on other platforms, like Linux, the assumption is
made
>> that the whole program is built with debug info - OSX is different
because
>> it has these system libraries for drivers that break this convention
(&
>> because LLDB can't handle this situation) - so, because the system
itself
>> breaks the assumption, the default is to turn off the assumption)
>>
>> I assumed your proposal would only add this debug info to describe the
>> vtable constant where the vtable is defined. Which would break OSX.
>>
>> If the idea would be to, in OSX (& other -fstandalone-debug
>> situations/platforms/users) would be to include this vtable DIE even
where
>> the vtable is not defined - that adds a bit more debug info & also
it means
>> debug info describing the declaration of a variable, also something we
>> haven't really done in LLVM before - again, technically possible,
but a
>> nuance I'd call out/want to be aware of/think about/talk about
(hence this
>> conversation), etc.
>>
>>
>>>
>>>> I can go into more detail there - but there are certainly some
annoying
>>>> edge cases/questions I have here :/
>>>>
>>>
>>> Constructive alternative?
>>>
>>
>> Not sure - not saying what your proposing isn't workable - but I do
want
>> to understand the practical/implementation details a bit to see how it
>> plays out - hence the conversation above.
>>
>
> FWIW, i don't have a lot of time/energy to push this, so i'm pretty
much
> going to bow out at this point and leave folks to their own devices. I just
> wanted to point out there are other solutions that would likely work a lot
> better over time.
>
>
>>
>>
>>> Right now, relying on *more* names, besides being huge in a lot of
>>> binaries,  relies on the demangler producing certain text (which is
not
>>> guaranteed)
>>> That text has to exactly match the text of some other symbol (which
is
>>> not guaranteed).
>>>
>>
>> *nod* I agree that the name matching based on demangling is a bad idea.
>>
>>
>>> That 10 second delay you get sometimes with going to print a C++
symbol
>>> in a large binary?
>>>
>>> That's this lookup.
>>>
>>> So right now it:
>>> 1. Uses a ton of memory
>>> 2. Uses a ton of time
>>> 3. Doesn't work all the time (depends on demanglers, and there
are very
>>> weird edge cases here).
>>>
>>> Adding linkage names will not change any of these, whereas adding a
>>> DWARF extension fixes all three, forever.
>>>
>>
>> Not sure I follow this - debuggers do lots of name lookups, I
would've
>> thought linkage name<>linkage name lookup could be somewhat
practical
>> (without all the fuzzy matching logic).
>>
>
> You'd think it would be optimized for this, but for GDB, it will now
pull
> in every symbol table looking for the name, until it finds it.  It does
> not, for example, build a global index of names so it knows what CU to go
> read from or anything smart like that.
> (it's a little more nuanced than this, but in practice, not)
>
>>
>>
>>> I don't even care about the details of the extension, my
overriding
>>> constraint is "please don't extend this hack further given
the above".
>>>
>>
>> Mangled to demangled name matching seems like a hack - matching the
>> mangled names doesn't seem like such a hack to me - but, yeah,
I'm totally
>> open to an address based solution as you're suggesting, just trying
to
>> figure out the details/issues.
>>
>
> At the time, the mangled name was not available anywhere.
> It looks like name() is supposed to now return the mangled name in the
> itanium ABI.
> So theoretically, you could just change GDB to call the name function(),
> look that up in the minimal symbol tables (name->address mappings,
without
> debug info), and go to the full symbol table info for that address.  This
> avoids needing the DW_AT_name in the debuginfo to match, only the name in
> the symbol table.
>
> This will break if you use -fno-rtti, whereas the vtable way (either
> existing or proposed) would still work.
>
> G++ actually *had* linkage names for types for a long time in the debug
> info, and deliberately removed them due to space usage.
>
>
>> Have you got a link/steps to a sample/way to get GCC to produce this
sort
>> of debug info? (at least with 6.3 using C++ I don't see any debug
info like
>> this describing a vtable)
>>
>
> Yeah, nothing does it yet.
> Bug tom tromey,  who did it for Rust, not C++
>
>
>> - Dave
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180305/bac35f5e/attachment.html>

On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <ripopov at gmail.com> wrote:
> I don't understand how extra vtable ref DIE will help in case on
> non-polymorphic classes. If you remove virtual destructor from example,
> vtable won't be generated for class, but DWARF will still have
incorrect
> ambiguous names for types.
>
1. Calling them incorrect is ... not right.  As Andrew quoted on the gdb
mailing list, this is what DWARF specifies should happen, so they are
correct by spec. If you believe the spec is wrong, file an issue on the
DWARF web site and discuss it on the mailing list, and bring back the
consensus of the committee as to what to do :)

2. The failure that was cited on the gdb mailing list only occurs on
polymorphic classes.   If you have it occurring on non-polymorphic classes,
that seems like a very different problem, and probably related to the fact
that GDB does not know how to assemble or parse C++ names properly in some
cases.  Otherwise, this would occur on literally every class you saw in
GDB, and that's definitely not the case:)

The only reason linkage names would fix that issue is because they provide
an exact match to GDB's parsing failure.
You should just fix GDB.
(GDB already knows how to collect and print out multiple symbols in the
case they have the same name, FWIW)


> It will become a problem when you need to use debuginfo as a C++ runtime
> reflection (I've already seen this in a couple of projects).
>
Or when you need to go back from LLVM IR to Clang AST (I've
already
> encountered this problem).
>
I don't understand these use cases well enough to help, but if you think
it's a serious issue, again, i'd take it up with the DWARF folks.

> I wonder if  abi::__cxa_demangle guarantees unambigous names?
>
No, it does not.

> If so, then I can just replace current incorrect names that Clang
> generates, with names from demangler. In this case I don't even need to
> patch gdb, it will work as is.
>
> -Roman
>
> 2018-03-05 10:46 GMT-08:00 Daniel Berlin <dberlin at dberlin.org>:
>
>>
>>
>> On Mon, Mar 5, 2018, 9:26 AM David Blaikie <dblaikie at
gmail.com> wrote:
>>
>>> On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at
dberlin.org>
>>> wrote:
>>>
>>>> On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie at
gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev
<
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via
llvm-dev <
>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As you may know modern C++ debuggers (GDB and LLDB)
support dynamic
>>>>>>> type identification for polymorphic objects, by
utilizing C++ RTTI.
>>>>>>> Unfortunately this feature does not work with Clang
and GDB >= 7.x
>>>>>>> .  The last compiler that worked well was G++ 6.x
>>>>>>>
>>>>>>> I've asked about this issue both on GDB and
LLDB maillists.
>>>>>>> Unfortunately it's hard or impossible to fix it
on debugger side.
>>>>>>>
>>>>>>
>>>>>> Errr, i posited a solution on the gdb mailing list that
i haven't
>>>>>> seen shot down so far, that doesn't require linkage
names, it only requires
>>>>>> one new attribute that is a DW_FORM_ref, and very
cheap.
>>>>>>
>>>>>
>>>>> FWIW, for C++ at least, neither Clang nor GCC (6.3) produce
any DWARF
>>>>> to describe the vtable itself (they describe the vtable
pointer inside the
>>>>> struct, but not the constant vtable array) - so it'll
be a bit more than
>>>>> one attribute, but the bytes describe the vtable (as a
global variable? Do
>>>>> we give it a name? (if so, we're back to paying that
cost)) first, then to
>>>>> add the reference from that to the type.
>>>>>
>>>>
>>>> Right, they produce a named symbol but not debug info.
>>>>
>>>> The only thing you need is a single DIE for that symbol, with a
single
>>>> ref.
>>>>
>>>
>>> When you say "a single DIE" what attributes are you
picturing that DIE
>>> having? If it has a single attribute, a ref_addr to the type, that
doesn't
>>> seem to provide anything useful. Presumably this DIE would need a
>>> DW_AT_location with the address of the vtable (with a relocation to
resolve
>>> that address, etc).
>>>
>>
>> Location and concrete type it belongs to.  That's the minimum you
should
>> need here.
>> You don't need the name, though it doesn't hurt.
>>
>>
>>> No name? No other identifying features? I don't think we've
ever really
>>> produced DIEs like that, though it sounds OK to me.
>>>
>>>
>>>>
>>>> (IE they just need to be able to say "find me the DIE for
this address
>>>> range", have it get to the vtable DIE, and get to the
concrete type die)
>>>>
>>>>
>>>>>
>>>>> & I'm not sure what Apple would do or anyone else
that has libraries
>>>>> without debug info shipped & users have to debug them
(this is what broke
>>>>> -fno-standalone-debug for Apple - their driver API which
ships without
>>>>> debug info of its own, has strong vtables in it).
>>>>>
>>>>
>>>> I'm confused.
>>>> This already seems to have  has the same issue?
>>>> Just because it uses one linker symbol, it still requires full
debug
>>>> info to print the type anyway.
>>>>
>>> So if it's gone, nothing changes.
>>>>
>>>
>>> Sorry, I don't quite understand your comment here - could you
explain it
>>> in more detail - the steps/issues you're seeing?
>>>
>>
>> I think we are starting from different positions here, so let me add a
>> few pieces of data and see how it helps.
>>
>> Let's assume the below is true and it won't work on OSX as
described (i'm
>> certainly in no place to disagree).
>>
>> Some data points:
>>
>> 1. LLDB works just fine on Darwin (it appears to do the same thing we
did
>> in gdb, staring at source/Plugins/LanguageRunt
>> ime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp)
>>
>> 2. GDB does not work on Darwin at all for any real debugging right now
>> (You can't debug llvm with it, for example).  There are barely
working
>> versions here and there.  The startup time to debug an "opt"
binary from
>> llvm is well over 2 minutes alone to get to a prompt just from typing
"gdb
>> bin/opt". It requires 4 gigs of ram.  It usually fails to print
most
>> symbols/types/crashes calling functions, blah blah blah.
>> You can't even quit most of the time without hitting an assert.
>> (gdb) q
>> thread.c:93: internal-error: struct thread_info *inferior_thread():
>> Assertion `tp' failed.
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.
>> Quit this debugging session? (y or n) y
>>
>>
>>
>> 3. On every platform, GDB will have to continue to use what it does now
>> as a fallback anyway, as all existing binaries will not be rebuilt.
>> 4. Ditto LLDB
>>
>> So for GDB, it doesn't really matter whether it breaks OSX, to
start.
>> Even if it did, it will still work as well or as not well as it has in
the
>> past :)
>>
>> LLDB works, and should work as well as it did with or without this as
>> well.
>>
>> Given all that: No matter what we do, LLDB and GDB will continue to
work
>> exactly as well or as broken as they have before on OSX. Nothing will
>> change.
>>
>> So i wouldn't call it broken, i'd call it, at worst,
inapplicable to
>> certain situations on OSX, and triggering a fallback :)
>>
>>
>>
>>> I'll try to do the same:
>>> Currently the DWARF type information (the actual DW_TAG_class_type
DIE
>>> with the full definition of the class - its members, etc) on OSX
goes
>>> everywhere the type is used (rather than only in the object files
where the
>>> vtable is defined) to ensure that types defined in objects built
without
>>> debug info, but used in objects built with debug info can still be
>>> debugged. (whereas on other platforms, like Linux, the assumption
is made
>>> that the whole program is built with debug info - OSX is different
because
>>> it has these system libraries for drivers that break this
convention (&
>>> because LLDB can't handle this situation) - so, because the
system itself
>>> breaks the assumption, the default is to turn off the assumption)
>>>
>>> I assumed your proposal would only add this debug info to describe
the
>>> vtable constant where the vtable is defined. Which would break OSX.
>>>
>>> If the idea would be to, in OSX (& other -fstandalone-debug
>>> situations/platforms/users) would be to include this vtable DIE
even where
>>> the vtable is not defined - that adds a bit more debug info &
also it means
>>> debug info describing the declaration of a variable, also something
we
>>> haven't really done in LLVM before - again, technically
possible, but a
>>> nuance I'd call out/want to be aware of/think about/talk about
(hence this
>>> conversation), etc.
>>>
>>>
>>>>
>>>>> I can go into more detail there - but there are certainly
some
>>>>> annoying edge cases/questions I have here :/
>>>>>
>>>>
>>>> Constructive alternative?
>>>>
>>>
>>> Not sure - not saying what your proposing isn't workable - but
I do want
>>> to understand the practical/implementation details a bit to see how
it
>>> plays out - hence the conversation above.
>>>
>>
>> FWIW, i don't have a lot of time/energy to push this, so i'm
pretty much
>> going to bow out at this point and leave folks to their own devices. I
just
>> wanted to point out there are other solutions that would likely work a
lot
>> better over time.
>>
>>
>>>
>>>
>>>> Right now, relying on *more* names, besides being huge in a lot
of
>>>> binaries,  relies on the demangler producing certain text
(which is not
>>>> guaranteed)
>>>> That text has to exactly match the text of some other symbol
(which is
>>>> not guaranteed).
>>>>
>>>
>>> *nod* I agree that the name matching based on demangling is a bad
idea.
>>>
>>>
>>>> That 10 second delay you get sometimes with going to print a
C++ symbol
>>>> in a large binary?
>>>>
>>>> That's this lookup.
>>>>
>>>> So right now it:
>>>> 1. Uses a ton of memory
>>>> 2. Uses a ton of time
>>>> 3. Doesn't work all the time (depends on demanglers, and
there are very
>>>> weird edge cases here).
>>>>
>>>> Adding linkage names will not change any of these, whereas
adding a
>>>> DWARF extension fixes all three, forever.
>>>>
>>>
>>> Not sure I follow this - debuggers do lots of name lookups, I
would've
>>> thought linkage name<>linkage name lookup could be somewhat
practical
>>> (without all the fuzzy matching logic).
>>>
>>
>> You'd think it would be optimized for this, but for GDB, it will
now pull
>> in every symbol table looking for the name, until it finds it.  It does
>> not, for example, build a global index of names so it knows what CU to
go
>> read from or anything smart like that.
>> (it's a little more nuanced than this, but in practice, not)
>>
>>>
>>>
>>>> I don't even care about the details of the extension, my
overriding
>>>> constraint is "please don't extend this hack further
given the above".
>>>>
>>>
>>> Mangled to demangled name matching seems like a hack - matching the
>>> mangled names doesn't seem like such a hack to me - but, yeah,
I'm totally
>>> open to an address based solution as you're suggesting, just
trying to
>>> figure out the details/issues.
>>>
>>
>> At the time, the mangled name was not available anywhere.
>> It looks like name() is supposed to now return the mangled name in the
>> itanium ABI.
>> So theoretically, you could just change GDB to call the name
function(),
>> look that up in the minimal symbol tables (name->address mappings,
without
>> debug info), and go to the full symbol table info for that address. 
This
>> avoids needing the DW_AT_name in the debuginfo to match, only the name
in
>> the symbol table.
>>
>> This will break if you use -fno-rtti, whereas the vtable way (either
>> existing or proposed) would still work.
>>
>> G++ actually *had* linkage names for types for a long time in the debug
>> info, and deliberately removed them due to space usage.
>>
>>
>>> Have you got a link/steps to a sample/way to get GCC to produce
this
>>> sort of debug info? (at least with 6.3 using C++ I don't see
any debug info
>>> like this describing a vtable)
>>>
>>
>> Yeah, nothing does it yet.
>> Bug tom tromey,  who did it for Rust, not C++
>>
>>
>>> - Dave
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/40e2d02c/attachment.html>

On Mon, Mar 5, 2018 at 11:55 PM Roman Popov <ripopov at gmail.com> wrote:
> I don't understand how extra vtable ref DIE will help in case on
> non-polymorphic classes.
>
The case we seem to be discussing is about dynamic types (types with
vtables). Non-dynamic types don't have type info in the object code to
compare against/match/test to find the dynamic type of an object (eg: you
can't dynamic_cast or use typeid on a type without a vtable).

> If you remove virtual destructor from example, vtable won't be
generated
> for class, but DWARF will still have incorrect ambiguous names for types.
>
As I've noted: Having ambiguous names for a type is something that should
be fixed because otherwise a debugger's going to get pretty confused about
matching types up between TUs.

But unambiguous doesn't necessarily mean "exactly the same name as a
certain demangler produces".

> It will become a problem when you need to use debuginfo as a C++ runtime
> reflection (I've already seen this in a couple of projects).
>
Or when you need to go back from LLVM IR to Clang AST (I've
already
> encountered this problem).
>
Not sure I quite follow these two points - though they're quite different
from the issues discussed so far in terms of motivation/solutions - so
might be worth diving into them further to understand if/how they could be
supported.

> I wonder if  abi::__cxa_demangle guarantees unambigous names?  If so, then
> I can just replace current incorrect names that Clang generates, with names
> from demangler. In this case I don't even need to patch gdb, it will
work
> as is.
>
The problem is that the ABI doesn't guarantee any particular demangling -
different implementations could demangle differently (eg:
"(unsigned)1"
versus "1u" for example). Making a strict contract between the
demangler
and the pretty printed names is probably not a workable idea.

>
> -Roman
>
> 2018-03-05 10:46 GMT-08:00 Daniel Berlin <dberlin at dberlin.org>:
>
>>
>>
>> On Mon, Mar 5, 2018, 9:26 AM David Blaikie <dblaikie at
gmail.com> wrote:
>>
>>> On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at
dberlin.org>
>>> wrote:
>>>
>>>> On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie at
gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via llvm-dev
<
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via
llvm-dev <
>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> As you may know modern C++ debuggers (GDB and LLDB)
support dynamic
>>>>>>> type identification for polymorphic objects, by
utilizing C++ RTTI.
>>>>>>> Unfortunately this feature does not work with Clang
and GDB >= 7.x
>>>>>>> .  The last compiler that worked well was G++ 6.x
>>>>>>>
>>>>>>> I've asked about this issue both on GDB and
LLDB maillists.
>>>>>>> Unfortunately it's hard or impossible to fix it
on debugger side.
>>>>>>>
>>>>>>
>>>>>> Errr, i posited a solution on the gdb mailing list that
i haven't
>>>>>> seen shot down so far, that doesn't require linkage
names, it only requires
>>>>>> one new attribute that is a DW_FORM_ref, and very
cheap.
>>>>>>
>>>>>
>>>>> FWIW, for C++ at least, neither Clang nor GCC (6.3) produce
any DWARF
>>>>> to describe the vtable itself (they describe the vtable
pointer inside the
>>>>> struct, but not the constant vtable array) - so it'll
be a bit more than
>>>>> one attribute, but the bytes describe the vtable (as a
global variable? Do
>>>>> we give it a name? (if so, we're back to paying that
cost)) first, then to
>>>>> add the reference from that to the type.
>>>>>
>>>>
>>>> Right, they produce a named symbol but not debug info.
>>>>
>>>> The only thing you need is a single DIE for that symbol, with a
single
>>>> ref.
>>>>
>>>
>>> When you say "a single DIE" what attributes are you
picturing that DIE
>>> having? If it has a single attribute, a ref_addr to the type, that
doesn't
>>> seem to provide anything useful. Presumably this DIE would need a
>>> DW_AT_location with the address of the vtable (with a relocation to
resolve
>>> that address, etc).
>>>
>>
>> Location and concrete type it belongs to.  That's the minimum you
should
>> need here.
>> You don't need the name, though it doesn't hurt.
>>
>>
>>> No name? No other identifying features? I don't think we've
ever really
>>> produced DIEs like that, though it sounds OK to me.
>>>
>>>
>>>>
>>>> (IE they just need to be able to say "find me the DIE for
this address
>>>> range", have it get to the vtable DIE, and get to the
concrete type die)
>>>>
>>>>
>>>>>
>>>>> & I'm not sure what Apple would do or anyone else
that has libraries
>>>>> without debug info shipped & users have to debug them
(this is what broke
>>>>> -fno-standalone-debug for Apple - their driver API which
ships without
>>>>> debug info of its own, has strong vtables in it).
>>>>>
>>>>
>>>> I'm confused.
>>>> This already seems to have  has the same issue?
>>>> Just because it uses one linker symbol, it still requires full
debug
>>>> info to print the type anyway.
>>>>
>>> So if it's gone, nothing changes.
>>>>
>>>
>>> Sorry, I don't quite understand your comment here - could you
explain it
>>> in more detail - the steps/issues you're seeing?
>>>
>>
>> I think we are starting from different positions here, so let me add a
>> few pieces of data and see how it helps.
>>
>> Let's assume the below is true and it won't work on OSX as
described (i'm
>> certainly in no place to disagree).
>>
>> Some data points:
>>
>> 1. LLDB works just fine on Darwin (it appears to do the same thing we
did
>> in gdb, staring
>> at
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp)
>>
>> 2. GDB does not work on Darwin at all for any real debugging right now
>> (You can't debug llvm with it, for example).  There are barely
working
>> versions here and there.  The startup time to debug an "opt"
binary from
>> llvm is well over 2 minutes alone to get to a prompt just from typing
"gdb
>> bin/opt". It requires 4 gigs of ram.  It usually fails to print
most
>> symbols/types/crashes calling functions, blah blah blah.
>> You can't even quit most of the time without hitting an assert.
>> (gdb) q
>> thread.c:93: internal-error: struct thread_info *inferior_thread():
>> Assertion `tp' failed.
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.
>> Quit this debugging session? (y or n) y
>>
>>
>>
>> 3. On every platform, GDB will have to continue to use what it does now
>> as a fallback anyway, as all existing binaries will not be rebuilt.
>> 4. Ditto LLDB
>>
>> So for GDB, it doesn't really matter whether it breaks OSX, to
start.
>> Even if it did, it will still work as well or as not well as it has in
the
>> past :)
>>
>> LLDB works, and should work as well as it did with or without this as
>> well.
>>
>> Given all that: No matter what we do, LLDB and GDB will continue to
work
>> exactly as well or as broken as they have before on OSX. Nothing will
>> change.
>>
>> So i wouldn't call it broken, i'd call it, at worst,
inapplicable to
>> certain situations on OSX, and triggering a fallback :)
>>
>>
>>
>>> I'll try to do the same:
>>> Currently the DWARF type information (the actual DW_TAG_class_type
DIE
>>> with the full definition of the class - its members, etc) on OSX
goes
>>> everywhere the type is used (rather than only in the object files
where the
>>> vtable is defined) to ensure that types defined in objects built
without
>>> debug info, but used in objects built with debug info can still be
>>> debugged. (whereas on other platforms, like Linux, the assumption
is made
>>> that the whole program is built with debug info - OSX is different
because
>>> it has these system libraries for drivers that break this
convention (&
>>> because LLDB can't handle this situation) - so, because the
system itself
>>> breaks the assumption, the default is to turn off the assumption)
>>>
>>> I assumed your proposal would only add this debug info to describe
the
>>> vtable constant where the vtable is defined. Which would break OSX.
>>>
>>> If the idea would be to, in OSX (& other -fstandalone-debug
>>> situations/platforms/users) would be to include this vtable DIE
even where
>>> the vtable is not defined - that adds a bit more debug info &
also it means
>>> debug info describing the declaration of a variable, also something
we
>>> haven't really done in LLVM before - again, technically
possible, but a
>>> nuance I'd call out/want to be aware of/think about/talk about
(hence this
>>> conversation), etc.
>>>
>>>
>>>>
>>>>> I can go into more detail there - but there are certainly
some
>>>>> annoying edge cases/questions I have here :/
>>>>>
>>>>
>>>> Constructive alternative?
>>>>
>>>
>>> Not sure - not saying what your proposing isn't workable - but
I do want
>>> to understand the practical/implementation details a bit to see how
it
>>> plays out - hence the conversation above.
>>>
>>
>> FWIW, i don't have a lot of time/energy to push this, so i'm
pretty much
>> going to bow out at this point and leave folks to their own devices. I
just
>> wanted to point out there are other solutions that would likely work a
lot
>> better over time.
>>
>>
>>>
>>>
>>>> Right now, relying on *more* names, besides being huge in a lot
of
>>>> binaries,  relies on the demangler producing certain text
(which is not
>>>> guaranteed)
>>>> That text has to exactly match the text of some other symbol
(which is
>>>> not guaranteed).
>>>>
>>>
>>> *nod* I agree that the name matching based on demangling is a bad
idea.
>>>
>>>
>>>> That 10 second delay you get sometimes with going to print a
C++ symbol
>>>> in a large binary?
>>>>
>>>> That's this lookup.
>>>>
>>>> So right now it:
>>>> 1. Uses a ton of memory
>>>> 2. Uses a ton of time
>>>> 3. Doesn't work all the time (depends on demanglers, and
there are very
>>>> weird edge cases here).
>>>>
>>>> Adding linkage names will not change any of these, whereas
adding a
>>>> DWARF extension fixes all three, forever.
>>>>
>>>
>>> Not sure I follow this - debuggers do lots of name lookups, I
would've
>>> thought linkage name<>linkage name lookup could be somewhat
practical
>>> (without all the fuzzy matching logic).
>>>
>>
>> You'd think it would be optimized for this, but for GDB, it will
now pull
>> in every symbol table looking for the name, until it finds it.  It does
>> not, for example, build a global index of names so it knows what CU to
go
>> read from or anything smart like that.
>> (it's a little more nuanced than this, but in practice, not)
>>
>>>
>>>
>>>> I don't even care about the details of the extension, my
overriding
>>>> constraint is "please don't extend this hack further
given the above".
>>>>
>>>
>>> Mangled to demangled name matching seems like a hack - matching the
>>> mangled names doesn't seem like such a hack to me - but, yeah,
I'm totally
>>> open to an address based solution as you're suggesting, just
trying to
>>> figure out the details/issues.
>>>
>>
>> At the time, the mangled name was not available anywhere.
>> It looks like name() is supposed to now return the mangled name in the
>> itanium ABI.
>> So theoretically, you could just change GDB to call the name
function(),
>> look that up in the minimal symbol tables (name->address mappings,
without
>> debug info), and go to the full symbol table info for that address. 
This
>> avoids needing the DW_AT_name in the debuginfo to match, only the name
in
>> the symbol table.
>>
>> This will break if you use -fno-rtti, whereas the vtable way (either
>> existing or proposed) would still work.
>>
>> G++ actually *had* linkage names for types for a long time in the debug
>> info, and deliberately removed them due to space usage.
>>
>>
>>> Have you got a link/steps to a sample/way to get GCC to produce
this
>>> sort of debug info? (at least with 6.3 using C++ I don't see
any debug info
>>> like this describing a vtable)
>>>
>>
>> Yeah, nothing does it yet.
>> Bug tom tromey,  who did it for Rust, not C++
>>
>>
>>> - Dave
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/11f0deeb/attachment-0001.html>

>
> I wonder if  abi::__cxa_demangle guarantees unambigous names?
>>
>
> No, it does not.
>
Interesting. Can you give an example of type where it fails?
I'm currently working on hardware construction library for C++ (similar to
Chisel (which is written in Scala)). And since C++ has no standardized
reflection, I use DWARF as a source of reflection metadata. And in case of
G++ 6.3, which seem to emit same name names as abi::__cxa_demangle, it has
never failed so far in my case. And I have very diverse inputs.
In fact I was working on it for about a year, and I was thinking that it
how it supposed to work. Only after I upgraded to g++ 7 I've found out that
both modern g++ and clang do not emit unambiguous debuginfo.

2. The failure that was cited on the gdb mailing list only occurs
on
> polymorphic classes.   If you have it occurring on non-polymorphic classes,
> that seems like a very different problem, and probably related to the fact
> that GDB does not know how to assemble or parse C++ names properly in some
> cases.  Otherwise, this would occur on literally every class you saw in
> GDB, and that's definitely not the case:)

That is correct, these two problems are different. However they can be
solved together.

Consider for example if we had only standardized mangled names in debuginfo:

1) GDB can demangle them and pretty-print in interactive sessions
2) Since it is the same name in debuginfo and RTTI, no problems with
dynamic type identification in debugger
3) Since mangled names is unique for type, we can use it in any other
scenarios. For example I want to analyze state of process in debugger, and
then load it in Clang to do some source-to-source transformations. This is
what I've planned for my hardware construction library.

-Roman


2018-03-06 8:39 GMT-08:00 Daniel Berlin <dberlin at dberlin.org>:
>
>
> On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <ripopov at gmail.com>
wrote:
>
>> I don't understand how extra vtable ref DIE will help in case on
>> non-polymorphic classes. If you remove virtual destructor from example,
>> vtable won't be generated for class, but DWARF will still have
incorrect
>> ambiguous names for types.
>>
> 1. Calling them incorrect is ... not right.  As Andrew quoted on the gdb
> mailing list, this is what DWARF specifies should happen, so they are
> correct by spec. If you believe the spec is wrong, file an issue on the
> DWARF web site and discuss it on the mailing list, and bring back the
> consensus of the committee as to what to do :)
>
> 2. The failure that was cited on the gdb mailing list only occurs on
> polymorphic classes.   If you have it occurring on non-polymorphic classes,
> that seems like a very different problem, and probably related to the fact
> that GDB does not know how to assemble or parse C++ names properly in some
> cases.  Otherwise, this would occur on literally every class you saw in
> GDB, and that's definitely not the case:)
>
> The only reason linkage names would fix that issue is because they provide
> an exact match to GDB's parsing failure.
> You should just fix GDB.
> (GDB already knows how to collect and print out multiple symbols in the
> case they have the same name, FWIW)
>
>
>
>> It will become a problem when you need to use debuginfo as a C++
runtime
>> reflection (I've already seen this in a couple of projects).
>>
> Or when you need to go back from LLVM IR to Clang AST (I've already
>> encountered this problem).
>>
>
> I don't understand these use cases well enough to help, but if you
think
> it's a serious issue, again, i'd take it up with the DWARF folks.
>
>
>> I wonder if  abi::__cxa_demangle guarantees unambigous names?
>>
>
> No, it does not.
>
>
>> If so, then I can just replace current incorrect names that Clang
>> generates, with names from demangler. In this case I don't even
need to
>> patch gdb, it will work as is.
>>
>> -Roman
>>
>> 2018-03-05 10:46 GMT-08:00 Daniel Berlin <dberlin at
dberlin.org>:
>>
>>>
>>>
>>> On Mon, Mar 5, 2018, 9:26 AM David Blaikie <dblaikie at
gmail.com> wrote:
>>>
>>>> On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at
dberlin.org>
>>>> wrote:
>>>>
>>>>> On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie
at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via
llvm-dev <
>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via
llvm-dev <
>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> As you may know modern C++ debuggers (GDB and
LLDB) support dynamic
>>>>>>>> type identification for polymorphic objects, by
utilizing C++ RTTI.
>>>>>>>> Unfortunately this feature does not work with
Clang and GDB >= 7.x
>>>>>>>> .  The last compiler that worked well was G++
6.x
>>>>>>>>
>>>>>>>> I've asked about this issue both on GDB and
LLDB maillists.
>>>>>>>> Unfortunately it's hard or impossible to
fix it on debugger side.
>>>>>>>>
>>>>>>>
>>>>>>> Errr, i posited a solution on the gdb mailing list
that i haven't
>>>>>>> seen shot down so far, that doesn't require
linkage names, it only requires
>>>>>>> one new attribute that is a DW_FORM_ref, and very
cheap.
>>>>>>>
>>>>>>
>>>>>> FWIW, for C++ at least, neither Clang nor GCC (6.3)
produce any DWARF
>>>>>> to describe the vtable itself (they describe the vtable
pointer inside the
>>>>>> struct, but not the constant vtable array) - so
it'll be a bit more than
>>>>>> one attribute, but the bytes describe the vtable (as a
global variable? Do
>>>>>> we give it a name? (if so, we're back to paying
that cost)) first, then to
>>>>>> add the reference from that to the type.
>>>>>>
>>>>>
>>>>> Right, they produce a named symbol but not debug info.
>>>>>
>>>>> The only thing you need is a single DIE for that symbol,
with a single
>>>>> ref.
>>>>>
>>>>
>>>> When you say "a single DIE" what attributes are you
picturing that DIE
>>>> having? If it has a single attribute, a ref_addr to the type,
that doesn't
>>>> seem to provide anything useful. Presumably this DIE would need
a
>>>> DW_AT_location with the address of the vtable (with a
relocation to resolve
>>>> that address, etc).
>>>>
>>>
>>> Location and concrete type it belongs to.  That's the minimum
you should
>>> need here.
>>> You don't need the name, though it doesn't hurt.
>>>
>>>
>>>> No name? No other identifying features? I don't think
we've ever really
>>>> produced DIEs like that, though it sounds OK to me.
>>>>
>>>>
>>>>>
>>>>> (IE they just need to be able to say "find me the DIE
for this address
>>>>> range", have it get to the vtable DIE, and get to the
concrete type die)
>>>>>
>>>>>
>>>>>>
>>>>>> & I'm not sure what Apple would do or anyone
else that has libraries
>>>>>> without debug info shipped & users have to debug
them (this is what broke
>>>>>> -fno-standalone-debug for Apple - their driver API
which ships without
>>>>>> debug info of its own, has strong vtables in it).
>>>>>>
>>>>>
>>>>> I'm confused.
>>>>> This already seems to have  has the same issue?
>>>>> Just because it uses one linker symbol, it still requires
full debug
>>>>> info to print the type anyway.
>>>>>
>>>> So if it's gone, nothing changes.
>>>>>
>>>>
>>>> Sorry, I don't quite understand your comment here - could
you explain
>>>> it in more detail - the steps/issues you're seeing?
>>>>
>>>
>>> I think we are starting from different positions here, so let me
add a
>>> few pieces of data and see how it helps.
>>>
>>> Let's assume the below is true and it won't work on OSX as
described
>>> (i'm certainly in no place to disagree).
>>>
>>> Some data points:
>>>
>>> 1. LLDB works just fine on Darwin (it appears to do the same thing
we
>>> did in gdb, staring at source/Plugins/LanguageRunt
>>> ime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp)
>>>
>>> 2. GDB does not work on Darwin at all for any real debugging right
now
>>> (You can't debug llvm with it, for example).  There are barely
working
>>> versions here and there.  The startup time to debug an
"opt" binary from
>>> llvm is well over 2 minutes alone to get to a prompt just from
typing "gdb
>>> bin/opt". It requires 4 gigs of ram.  It usually fails to
print most
>>> symbols/types/crashes calling functions, blah blah blah.
>>> You can't even quit most of the time without hitting an assert.
>>> (gdb) q
>>> thread.c:93: internal-error: struct thread_info *inferior_thread():
>>> Assertion `tp' failed.
>>> A problem internal to GDB has been detected,
>>> further debugging may prove unreliable.
>>> Quit this debugging session? (y or n) y
>>>
>>>
>>>
>>> 3. On every platform, GDB will have to continue to use what it does
now
>>> as a fallback anyway, as all existing binaries will not be rebuilt.
>>> 4. Ditto LLDB
>>>
>>> So for GDB, it doesn't really matter whether it breaks OSX, to
start.
>>> Even if it did, it will still work as well or as not well as it has
in the
>>> past :)
>>>
>>> LLDB works, and should work as well as it did with or without this
as
>>> well.
>>>
>>> Given all that: No matter what we do, LLDB and GDB will continue to
work
>>> exactly as well or as broken as they have before on OSX. Nothing
will
>>> change.
>>>
>>> So i wouldn't call it broken, i'd call it, at worst,
inapplicable to
>>> certain situations on OSX, and triggering a fallback :)
>>>
>>>
>>>
>>>> I'll try to do the same:
>>>> Currently the DWARF type information (the actual
DW_TAG_class_type DIE
>>>> with the full definition of the class - its members, etc) on
OSX goes
>>>> everywhere the type is used (rather than only in the object
files where the
>>>> vtable is defined) to ensure that types defined in objects
built without
>>>> debug info, but used in objects built with debug info can still
be
>>>> debugged. (whereas on other platforms, like Linux, the
assumption is made
>>>> that the whole program is built with debug info - OSX is
different because
>>>> it has these system libraries for drivers that break this
convention (&
>>>> because LLDB can't handle this situation) - so, because the
system itself
>>>> breaks the assumption, the default is to turn off the
assumption)
>>>>
>>>> I assumed your proposal would only add this debug info to
describe the
>>>> vtable constant where the vtable is defined. Which would break
OSX.
>>>>
>>>> If the idea would be to, in OSX (& other -fstandalone-debug
>>>> situations/platforms/users) would be to include this vtable DIE
even where
>>>> the vtable is not defined - that adds a bit more debug info
& also it means
>>>> debug info describing the declaration of a variable, also
something we
>>>> haven't really done in LLVM before - again, technically
possible, but a
>>>> nuance I'd call out/want to be aware of/think about/talk
about (hence this
>>>> conversation), etc.
>>>>
>>>>
>>>>>
>>>>>> I can go into more detail there - but there are
certainly some
>>>>>> annoying edge cases/questions I have here :/
>>>>>>
>>>>>
>>>>> Constructive alternative?
>>>>>
>>>>
>>>> Not sure - not saying what your proposing isn't workable -
but I do
>>>> want to understand the practical/implementation details a bit
to see how it
>>>> plays out - hence the conversation above.
>>>>
>>>
>>> FWIW, i don't have a lot of time/energy to push this, so
i'm pretty much
>>> going to bow out at this point and leave folks to their own
devices. I just
>>> wanted to point out there are other solutions that would likely
work a lot
>>> better over time.
>>>
>>>
>>>>
>>>>
>>>>> Right now, relying on *more* names, besides being huge in a
lot of
>>>>> binaries,  relies on the demangler producing certain text
(which is not
>>>>> guaranteed)
>>>>> That text has to exactly match the text of some other
symbol (which is
>>>>> not guaranteed).
>>>>>
>>>>
>>>> *nod* I agree that the name matching based on demangling is a
bad idea.
>>>>
>>>>
>>>>> That 10 second delay you get sometimes with going to print
a C++
>>>>> symbol in a large binary?
>>>>>
>>>>> That's this lookup.
>>>>>
>>>>> So right now it:
>>>>> 1. Uses a ton of memory
>>>>> 2. Uses a ton of time
>>>>> 3. Doesn't work all the time (depends on demanglers,
and there are
>>>>> very weird edge cases here).
>>>>>
>>>>> Adding linkage names will not change any of these, whereas
adding a
>>>>> DWARF extension fixes all three, forever.
>>>>>
>>>>
>>>> Not sure I follow this - debuggers do lots of name lookups, I
would've
>>>> thought linkage name<>linkage name lookup could be
somewhat practical
>>>> (without all the fuzzy matching logic).
>>>>
>>>
>>> You'd think it would be optimized for this, but for GDB, it
will now
>>> pull in every symbol table looking for the name, until it finds it.
It
>>> does not, for example, build a global index of names so it knows
what CU to
>>> go read from or anything smart like that.
>>> (it's a little more nuanced than this, but in practice, not)
>>>
>>>>
>>>>
>>>>> I don't even care about the details of the extension,
my overriding
>>>>> constraint is "please don't extend this hack
further given the above".
>>>>>
>>>>
>>>> Mangled to demangled name matching seems like a hack - matching
the
>>>> mangled names doesn't seem like such a hack to me - but,
yeah, I'm totally
>>>> open to an address based solution as you're suggesting,
just trying to
>>>> figure out the details/issues.
>>>>
>>>
>>> At the time, the mangled name was not available anywhere.
>>> It looks like name() is supposed to now return the mangled name in
the
>>> itanium ABI.
>>> So theoretically, you could just change GDB to call the name
function(),
>>> look that up in the minimal symbol tables (name->address
mappings, without
>>> debug info), and go to the full symbol table info for that address.
This
>>> avoids needing the DW_AT_name in the debuginfo to match, only the
name in
>>> the symbol table.
>>>
>>> This will break if you use -fno-rtti, whereas the vtable way
(either
>>> existing or proposed) would still work.
>>>
>>> G++ actually *had* linkage names for types for a long time in the
debug
>>> info, and deliberately removed them due to space usage.
>>>
>>>
>>>> Have you got a link/steps to a sample/way to get GCC to produce
this
>>>> sort of debug info? (at least with 6.3 using C++ I don't
see any debug info
>>>> like this describing a vtable)
>>>>
>>>
>>> Yeah, nothing does it yet.
>>> Bug tom tromey,  who did it for Rust, not C++
>>>
>>>
>>>> - Dave
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/b225118b/attachment.html>

On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <dberlin at dberlin.org>
wrote:
> On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <ripopov at gmail.com>
wrote:
>
>> I don't understand how extra vtable ref DIE will help in case on
>> non-polymorphic classes. If you remove virtual destructor from example,
>> vtable won't be generated for class, but DWARF will still have
incorrect
>> ambiguous names for types.
>>
> 1. Calling them incorrect is ... not right.  As Andrew quoted on the gdb
> mailing list, this is what DWARF specifies should happen,
>
Might be helpful to point to/include any details cited here for the purpose
of this conversation - a bit hard for the rest of us to follow along.

> so they are correct by spec. If you believe the spec is wrong, file an
> issue on the DWARF web site and discuss it on the mailing list, and bring
> back the consensus of the committee as to what to do :)
>
The ambiguous names are probably incorrect - having two distinct types that
have the same name's not really going to work out well for a consumer. (so
having the distinct types foo<11u> and foo<11> in source both
produce a
DWARF type named "foo<11>" I'd say is a bug that ought to be
fixed - as is
any other case where the names become ambiguous, otherwise matching up
types between TUs would become impossible, which would be not good)

> 2. The failure that was cited on the gdb mailing list only occurs on
> polymorphic classes.   If you have it occurring on non-polymorphic classes,
> that seems like a very different problem, and probably related to the fact
> that GDB does not know how to assemble or parse C++ names properly in some
> cases.  Otherwise, this would occur on literally every class you saw in
> GDB, and that's definitely not the case:)
>
Sounds like Roman's talking about other use cases apart from GDB.

> The only reason linkage names would fix that issue is because they provide
> an exact match to GDB's parsing failure.
>
Not sure I follow this - providing linkage names would provide a reliable
mechanism to match the vtable symbol. There wouldn't need to be any
parsing, or any failure of parsing involved.

But, yes, addresses would be potentially a better description rather than
having to match names in the object's symbol table.

> You should just fix GDB.
> (GDB already knows how to collect and print out multiple symbols in the
> case they have the same name, FWIW)
>
>
>
>> It will become a problem when you need to use debuginfo as a C++
runtime
>> reflection (I've already seen this in a couple of projects).
>>
> Or when you need to go back from LLVM IR to Clang AST (I've already
>> encountered this problem).
>>
>
> I don't understand these use cases well enough to help, but if you
think
> it's a serious issue, again, i'd take it up with the DWARF folks.
>
>
>> I wonder if  abi::__cxa_demangle guarantees unambigous names?
>>
>
> No, it does not.
>
>
>> If so, then I can just replace current incorrect names that Clang
>> generates, with names from demangler. In this case I don't even
need to
>> patch gdb, it will work as is.
>>
>> -Roman
>>
>> 2018-03-05 10:46 GMT-08:00 Daniel Berlin <dberlin at
dberlin.org>:
>>
>>>
>>>
>>> On Mon, Mar 5, 2018, 9:26 AM David Blaikie <dblaikie at
gmail.com> wrote:
>>>
>>>> On Mon, Mar 5, 2018 at 9:09 AM Daniel Berlin <dberlin at
dberlin.org>
>>>> wrote:
>>>>
>>>>> On Mon, Mar 5, 2018 at 8:37 AM, David Blaikie <dblaikie
at gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Mar 3, 2018 at 8:20 PM Daniel Berlin via
llvm-dev <
>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via
llvm-dev <
>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> As you may know modern C++ debuggers (GDB and
LLDB) support dynamic
>>>>>>>> type identification for polymorphic objects, by
utilizing C++ RTTI.
>>>>>>>> Unfortunately this feature does not work with
Clang and GDB >= 7.x
>>>>>>>> .  The last compiler that worked well was G++
6.x
>>>>>>>>
>>>>>>>> I've asked about this issue both on GDB and
LLDB maillists.
>>>>>>>> Unfortunately it's hard or impossible to
fix it on debugger side.
>>>>>>>>
>>>>>>>
>>>>>>> Errr, i posited a solution on the gdb mailing list
that i haven't
>>>>>>> seen shot down so far, that doesn't require
linkage names, it only requires
>>>>>>> one new attribute that is a DW_FORM_ref, and very
cheap.
>>>>>>>
>>>>>>
>>>>>> FWIW, for C++ at least, neither Clang nor GCC (6.3)
produce any DWARF
>>>>>> to describe the vtable itself (they describe the vtable
pointer inside the
>>>>>> struct, but not the constant vtable array) - so
it'll be a bit more than
>>>>>> one attribute, but the bytes describe the vtable (as a
global variable? Do
>>>>>> we give it a name? (if so, we're back to paying
that cost)) first, then to
>>>>>> add the reference from that to the type.
>>>>>>
>>>>>
>>>>> Right, they produce a named symbol but not debug info.
>>>>>
>>>>> The only thing you need is a single DIE for that symbol,
with a single
>>>>> ref.
>>>>>
>>>>
>>>> When you say "a single DIE" what attributes are you
picturing that DIE
>>>> having? If it has a single attribute, a ref_addr to the type,
that doesn't
>>>> seem to provide anything useful. Presumably this DIE would need
a
>>>> DW_AT_location with the address of the vtable (with a
relocation to resolve
>>>> that address, etc).
>>>>
>>>
>>> Location and concrete type it belongs to.  That's the minimum
you should
>>> need here.
>>> You don't need the name, though it doesn't hurt.
>>>
>>>
>>>> No name? No other identifying features? I don't think
we've ever really
>>>> produced DIEs like that, though it sounds OK to me.
>>>>
>>>>
>>>>>
>>>>> (IE they just need to be able to say "find me the DIE
for this address
>>>>> range", have it get to the vtable DIE, and get to the
concrete type die)
>>>>>
>>>>>
>>>>>>
>>>>>> & I'm not sure what Apple would do or anyone
else that has libraries
>>>>>> without debug info shipped & users have to debug
them (this is what broke
>>>>>> -fno-standalone-debug for Apple - their driver API
which ships without
>>>>>> debug info of its own, has strong vtables in it).
>>>>>>
>>>>>
>>>>> I'm confused.
>>>>> This already seems to have  has the same issue?
>>>>> Just because it uses one linker symbol, it still requires
full debug
>>>>> info to print the type anyway.
>>>>>
>>>> So if it's gone, nothing changes.
>>>>>
>>>>
>>>> Sorry, I don't quite understand your comment here - could
you explain
>>>> it in more detail - the steps/issues you're seeing?
>>>>
>>>
>>> I think we are starting from different positions here, so let me
add a
>>> few pieces of data and see how it helps.
>>>
>>> Let's assume the below is true and it won't work on OSX as
described
>>> (i'm certainly in no place to disagree).
>>>
>>> Some data points:
>>>
>>> 1. LLDB works just fine on Darwin (it appears to do the same thing
we
>>> did in gdb, staring
>>> at
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp)
>>>
>>> 2. GDB does not work on Darwin at all for any real debugging right
now
>>> (You can't debug llvm with it, for example).  There are barely
working
>>> versions here and there.  The startup time to debug an
"opt" binary from
>>> llvm is well over 2 minutes alone to get to a prompt just from
typing "gdb
>>> bin/opt". It requires 4 gigs of ram.  It usually fails to
print most
>>> symbols/types/crashes calling functions, blah blah blah.
>>> You can't even quit most of the time without hitting an assert.
>>> (gdb) q
>>> thread.c:93: internal-error: struct thread_info *inferior_thread():
>>> Assertion `tp' failed.
>>> A problem internal to GDB has been detected,
>>> further debugging may prove unreliable.
>>> Quit this debugging session? (y or n) y
>>>
>>>
>>>
>>> 3. On every platform, GDB will have to continue to use what it does
now
>>> as a fallback anyway, as all existing binaries will not be rebuilt.
>>> 4. Ditto LLDB
>>>
>>> So for GDB, it doesn't really matter whether it breaks OSX, to
start.
>>> Even if it did, it will still work as well or as not well as it has
in the
>>> past :)
>>>
>>> LLDB works, and should work as well as it did with or without this
as
>>> well.
>>>
>>> Given all that: No matter what we do, LLDB and GDB will continue to
work
>>> exactly as well or as broken as they have before on OSX. Nothing
will
>>> change.
>>>
>>> So i wouldn't call it broken, i'd call it, at worst,
inapplicable to
>>> certain situations on OSX, and triggering a fallback :)
>>>
>>>
>>>
>>>> I'll try to do the same:
>>>> Currently the DWARF type information (the actual
DW_TAG_class_type DIE
>>>> with the full definition of the class - its members, etc) on
OSX goes
>>>> everywhere the type is used (rather than only in the object
files where the
>>>> vtable is defined) to ensure that types defined in objects
built without
>>>> debug info, but used in objects built with debug info can still
be
>>>> debugged. (whereas on other platforms, like Linux, the
assumption is made
>>>> that the whole program is built with debug info - OSX is
different because
>>>> it has these system libraries for drivers that break this
convention (&
>>>> because LLDB can't handle this situation) - so, because the
system itself
>>>> breaks the assumption, the default is to turn off the
assumption)
>>>>
>>>> I assumed your proposal would only add this debug info to
describe the
>>>> vtable constant where the vtable is defined. Which would break
OSX.
>>>>
>>>> If the idea would be to, in OSX (& other -fstandalone-debug
>>>> situations/platforms/users) would be to include this vtable DIE
even where
>>>> the vtable is not defined - that adds a bit more debug info
& also it means
>>>> debug info describing the declaration of a variable, also
something we
>>>> haven't really done in LLVM before - again, technically
possible, but a
>>>> nuance I'd call out/want to be aware of/think about/talk
about (hence this
>>>> conversation), etc.
>>>>
>>>>
>>>>>
>>>>>> I can go into more detail there - but there are
certainly some
>>>>>> annoying edge cases/questions I have here :/
>>>>>>
>>>>>
>>>>> Constructive alternative?
>>>>>
>>>>
>>>> Not sure - not saying what your proposing isn't workable -
but I do
>>>> want to understand the practical/implementation details a bit
to see how it
>>>> plays out - hence the conversation above.
>>>>
>>>
>>> FWIW, i don't have a lot of time/energy to push this, so
i'm pretty much
>>> going to bow out at this point and leave folks to their own
devices. I just
>>> wanted to point out there are other solutions that would likely
work a lot
>>> better over time.
>>>
>>>
>>>>
>>>>
>>>>> Right now, relying on *more* names, besides being huge in a
lot of
>>>>> binaries,  relies on the demangler producing certain text
(which is not
>>>>> guaranteed)
>>>>> That text has to exactly match the text of some other
symbol (which is
>>>>> not guaranteed).
>>>>>
>>>>
>>>> *nod* I agree that the name matching based on demangling is a
bad idea.
>>>>
>>>>
>>>>> That 10 second delay you get sometimes with going to print
a C++
>>>>> symbol in a large binary?
>>>>>
>>>>> That's this lookup.
>>>>>
>>>>> So right now it:
>>>>> 1. Uses a ton of memory
>>>>> 2. Uses a ton of time
>>>>> 3. Doesn't work all the time (depends on demanglers,
and there are
>>>>> very weird edge cases here).
>>>>>
>>>>> Adding linkage names will not change any of these, whereas
adding a
>>>>> DWARF extension fixes all three, forever.
>>>>>
>>>>
>>>> Not sure I follow this - debuggers do lots of name lookups, I
would've
>>>> thought linkage name<>linkage name lookup could be
somewhat practical
>>>> (without all the fuzzy matching logic).
>>>>
>>>
>>> You'd think it would be optimized for this, but for GDB, it
will now
>>> pull in every symbol table looking for the name, until it finds it.
It
>>> does not, for example, build a global index of names so it knows
what CU to
>>> go read from or anything smart like that.
>>> (it's a little more nuanced than this, but in practice, not)
>>>
>>>>
>>>>
>>>>> I don't even care about the details of the extension,
my overriding
>>>>> constraint is "please don't extend this hack
further given the above".
>>>>>
>>>>
>>>> Mangled to demangled name matching seems like a hack - matching
the
>>>> mangled names doesn't seem like such a hack to me - but,
yeah, I'm totally
>>>> open to an address based solution as you're suggesting,
just trying to
>>>> figure out the details/issues.
>>>>
>>>
>>> At the time, the mangled name was not available anywhere.
>>> It looks like name() is supposed to now return the mangled name in
the
>>> itanium ABI.
>>> So theoretically, you could just change GDB to call the name
function(),
>>> look that up in the minimal symbol tables (name->address
mappings, without
>>> debug info), and go to the full symbol table info for that address.
This
>>> avoids needing the DW_AT_name in the debuginfo to match, only the
name in
>>> the symbol table.
>>>
>>> This will break if you use -fno-rtti, whereas the vtable way
(either
>>> existing or proposed) would still work.
>>>
>>> G++ actually *had* linkage names for types for a long time in the
debug
>>> info, and deliberately removed them due to space usage.
>>>
>>>
>>>> Have you got a link/steps to a sample/way to get GCC to produce
this
>>>> sort of debug info? (at least with 6.3 using C++ I don't
see any debug info
>>>> like this describing a vtable)
>>>>
>>>
>>> Yeah, nothing does it yet.
>>> Bug tom tromey,  who did it for Rust, not C++
>>>
>>>
>>>> - Dave
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/f06aa922/attachment.html>