CarlosAlbertoEnciso wrote:
As pointed out by @Michael137
> If we're given the `_vtable$` artificial member, there's nothing useful we
> can do with it right?
```
0x00000042: DW_TAG_variable
DW_AT_specification (0x0000005c "_vtable$")
DW_AT_alignment (8)
DW_AT_location (DW_OP_addrx 0x1)
DW_AT_linkage_name ("_ZTV8CDerived")
0x0000004c: DW_TAG_structure_type ("CDerived")
...
0x0000005c: DW_TAG_variable
DW_AT_name ("_vtable$")
DW_AT_type (0x00000041 "void *")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_artificial (true)
DW_AT_accessibility (DW_ACCESS_private)
DW_AT_containing_type <0x00000042> --> VTable global variable
...
.debug_addr contents:
Addrs: [
0x0000000000000000
0x0000000000000000 <- DW_OP_addrx 0x1
0x0000000000000000
]
```
And taking a variation of what @tromey described, maybe we can add a
`DW_AT_containing_type` pointing back to the global variable, providing 2 ways
to use the new vtable information entry:
- Given the `_vtable$` artificial member: use the `DW_AT_containing_type` to
find the vtable global variable.
- Given the vtable global variable: use the `DW_AT_specification` to find the
object definition.
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
