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
__
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-subpro
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
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 - f
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 t
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
10 matches
Mail list logo
