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

[David Blaikie via llvm-dev]

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).

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'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.


> 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).


> 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.

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)

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180305/5ec056bc/attachment.html>