[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: > > 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
[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: > 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: > As a note - when you say "at the CU scope" do you mean a direct child of the > CU, or anything outside a function or class definition? (ie: could be inside > a namespace) - Clang puts definitions, I think, in the namespace nearest the > declaration for the definition - compare these: > https://godbolt.org/z/EoK4noe7o Outside of function bodies is probably good enough. For me conceptually the vtable is an artificial global, but I could understand wanting it to be in a namespace or whatever. And really if one were going that route, having the vtable object be a function-scoped static would also make sense. It's just that this incurs a new cost on the debuginfo reader -- but not for any deep source-related reason, because these aren't source-accessible objects anyway. 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: > Uploaded a patch that eliminates the global variable and it moves the vtable > information into the static member; in that way, a consumer always will have > access to the vtable information, just by having the object instance or the > object definition. IIUC this means that to see the vtable for a class, the debugger has to scan the class declaration itself -- the vtable isn't a separate CU-level global variable but is instead a static member of the class. This approach won't work well for gdb. gdb tries not to scan DIEs that it does not need, in order to improve startup times. In particular it tries not to scan function bodies until necessary. OTOH having a separate global variable representing the vtable itself is reasonably easy to handle. And, it would solve the "function-local class" problem for gdb. 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: > My intent (haven't checked the patch) is that it'd be modeled as a static > member variable - so there'd be a declaration in the class, but a definition > DIE outside the class that'd be indexed by gdb OK, I'd have thought? (it'd go > in .debug_names, and gdb_index, I think - figure gdb would parse/index the > definition DIE?) I think this would be fine. The crucial thing, I think, is that there's some indication at the CU scope. This way the initial scan can take note of the global and its address; then fully read the CU if the class type is needed at some point. 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: Apologies if I missed it, but one thing I didn't see in the patch is a test for the case where a class is defined inside a function. Given the discussion [here](https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544), I guess this might not fully work correctly; but it seems to me that checking that the vtable symbol is global could be done and might provide some future-proofing. Thanks. 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] Non constant size and offset in DWARF (PR #141106)
tromey wrote: I rebased this and fixed up the mlir problem. I also changed how the overload resolution was done, so that a later patch that treats `nullptr` specially can be done without affecting existing call sites. https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Non constant size and offset in DWARF (PR #141106)
tromey wrote: >From what I can tell, those failures don't have anything to do with this patch. https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Non constant size and offset in DWARF (PR #141106)
tromey wrote: Rebased and adapted to the `LLVM_ABI` change. https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Non constant size and offset in DWARF (PR #141106)
@@ -966,20 +992,42 @@ class DIFixedPointType : public DIBasicType {
uint64_t SizeInBits, uint32_t AlignInBits, unsigned Encoding,
DIFlags Flags, unsigned Kind, int Factor, APInt Numerator,
APInt Denominator, StorageType Storage, bool ShouldCreate = true) {
+auto *SizeInBitsNode = ConstantAsMetadata::get(
+ConstantInt::get(Type::getInt64Ty(Context), SizeInBits));
+return getImpl(Context, Tag, getCanonicalMDString(Context, Name),
+ SizeInBitsNode, AlignInBits, Encoding, Flags, Kind, Factor,
+ Numerator, Denominator, Storage, ShouldCreate);
+ }
+ static DIFixedPointType *
+ getImpl(LLVMContext &Context, unsigned Tag, StringRef Name,
+ Metadata *SizeInBits, uint32_t AlignInBits, unsigned Encoding,
+ DIFlags Flags, unsigned Kind, int Factor, APInt Numerator,
+ APInt Denominator, StorageType Storage, bool ShouldCreate = true) {
return getImpl(Context, Tag, getCanonicalMDString(Context, Name),
SizeInBits, AlignInBits, Encoding, Flags, Kind, Factor,
Numerator, Denominator, Storage, ShouldCreate);
}
LLVM_ABI static DIFixedPointType *
getImpl(LLVMContext &Context, unsigned Tag, MDString *Name,
- uint64_t SizeInBits, uint32_t AlignInBits, unsigned Encoding,
+ uint32_t SizeInBits, uint32_t AlignInBits, unsigned Encoding,
tromey wrote:
I didn't mean to change the type of `SizeInBits` here. I don't think it is
harmful as is, but I'll fix it and upload a new patch shortly.
https://github.com/llvm/llvm-project/pull/141106
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Non constant size and offset in DWARF (PR #141106)
tromey wrote: Updated to fix a tiny error I'd introduced. https://github.com/llvm/llvm-project/pull/141106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
