[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)
tromey wrote:
> But, yeah, I wouldn't mind hearing more about lldb's
> needs/preferences/hopes/dreams for this feature so we might get a design
> that's more portable at least between SCE and LLDB. (bonus points if anyone's
> got GDB's needs in mind - perhaps @tromey might be able to lend us some
> insight as to how GDB does things and what they might be inclined to
> use/support to improve this feature area)
For C++, GDB knows the details of the Itanium ABI. When `set print object` is
enabled, it uses these to find the runtime type of an object. It's somewhat
buggy, though, since it too does not understand types local to a function.
For Rust, we added a feature to LLVM to enable this. In Rust, a "trait object"
has a vtable pointer and a pointer to the underlying real object. To discover
the type of this real object, the vtable is emitted like:
```
<1><2a>: Abbrev Number: 2 (DW_TAG_variable)
<2b> DW_AT_name: (indirect string, offset: 0xda):
as
core::ops::function::Fn<()>>::{vtable}
<2f> DW_AT_type: <0x3d>
<33> DW_AT_location: 9 byte block: 3 68 5e 5 0 0 0 0 0
(DW_OP_addr: 55e68)
<1><3d>: Abbrev Number: 3 (DW_TAG_structure_type)
<3e> DW_AT_containing_type: <0xb5>
<42> DW_AT_name: (indirect string, offset: 0x178):
as
core::ops::function::Fn<()>>::{vtable_type}
<46> DW_AT_byte_size : 48
<47> DW_AT_alignment : 8
... members ...
```
That is, the vtable is emitted as a global variable. It's type describes the
vtable itself (of course). But the vtable type has a `DW_AT_containing_type`
that points to the runtime type corresponding to this particular vtable.
I tend to think C++ should do something like this as well. The reason for this
approach is that it makes it simple to go from some C++ object in memory to the
runtime type: fetch the vtable pointer, look through the DWARF for the object
at this address (which can sometimes be problematic as pointed out earlier),
then examine the "containing type" to find the DWARF for the real type.
Existing code for Rust is
[here](https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp#L1039-L1045).
https://github.com/llvm/llvm-project/pull/130255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)
tromey wrote: `DW_AT_specification` has a fairly specific meaning in DWARF. I don't really understand why you want to link from the class type to the vtable (the reverse seems more useful to me), but I would suggest a new attribute, considering it is a new capability. The link from the class to the specific vtable even seems mildly incorrect, in that during object construction the vtable will go through several different values, not just one. Also linking from the vtable object to a member of the class seems less useful than the `DW_AT_containing_type` approach, where the link is explicitly to the type and not some member. https://github.com/llvm/llvm-project/pull/130255 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)
tromey wrote: > Removing the vtable global variable and moving the "location info" into the > static within the class, will work for the SCE debugger. I was thinking about this last night and wondering if the vtable will appear as a class member even if the class is local to a function? If so then it seems like this would be hard for gdb to find (can't speak for other debuggers). The issue being that gdb tends not to read DIEs that it thinks are uninteresting, and this means function bodies in general are skipped. If the vtable were a global-but-artificial object, then it would readily be found by the initial scan. https://github.com/llvm/llvm-project/pull/130255 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)
tromey wrote: > Given the _vtable$ artificial member: use the DW_AT_containing_type to find > the vtable global variable. It seems to me that this attribute should refer to a type and not a variable. https://github.com/llvm/llvm-project/pull/130255 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang][DebugInfo] Add symbol for debugger with VTable information. (PR #130255)
tromey wrote: > > The link from the class to the specific vtable even seems mildly incorrect, > > in that during object construction the vtable will go through several > > different values, not just one. > > Not sure I follow this - the object is only of the type, in some sense, when > it is pointing to that particular vtable. Yeah, I agree, sorry about that. https://github.com/llvm/llvm-project/pull/130255 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
