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
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
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
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
_
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 s
