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

[Daniel Berlin via cfe-dev]

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.

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

>
> I can go into more detail there - but there are certainly some annoying
> edge cases/questions I have here :/
>

Constructive alternative?

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

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.

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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180305/2789c762/attachment.html>