On Wed, Apr 23, 2025 at 7:46 PM Cary Coutant wrote:
>>
>> The first part of this is straightforward. The DWARF for Base will
>> contain a member for the vtable pointer, and that plus knowledge of
>> how the ABI lays out vtables allows the debugger to effectively do a
>> dynamic_cast to obtain a po
>
> The first part of this is straightforward. The DWARF for Base will
> contain a member for the vtable pointer, and that plus knowledge of
> how the ABI lays out vtables allows the debugger to effectively do a
> dynamic_cast to obtain a pointer to the most derived object.
> From there the vtable
Thanks. I've added this as Issue 250422.1.
https://dwarfstd.org/issues/250422.1.html
Would we want to delete the following paragraph? Quite possibly yes,
there is little reason to suggest repetition is a good idea.
>If the actual attribute form is itself `DW_FORM_indirect`,
>the indirection re
On Wed, Apr 23, 2025 at 3:14 PM David Blaikie wrote:
>
>
>
> On Wed, Apr 23, 2025 at 2:53 PM Kyle Huey wrote:
>>
>> On Wed, Apr 23, 2025 at 2:20 PM David Blaikie wrote:
>> >>
>> >> Do you object to anything I proposed other than removing the
>> >> representation of the anonymous class compilers
On Wed, Apr 23, 2025 at 2:20 PM David Blaikie wrote:
>>
>> Do you object to anything I proposed other than removing the
>> representation of the anonymous class compilers generate for lambdas?
>
>
> I'm not a /super/ fan of introducing a bunch of locals in addition to the
> member descriptions -
On Wed, Apr 23, 2025 at 2:53 PM Kyle Huey wrote:
> On Wed, Apr 23, 2025 at 2:20 PM David Blaikie wrote:
> >>
> >> Do you object to anything I proposed other than removing the
> >> representation of the anonymous class compilers generate for lambdas?
> >
> >
> > I'm not a /super/ fan of introduci
>
> Do you object to anything I proposed other than removing the
> representation of the anonymous class compilers generate for lambdas?
>
I'm not a /super/ fan of introducing a bunch of locals in addition to the
member descriptions - it'll be a bunch of extra DWARF that'd be nice to
avoid if we c
On 4/23/25 11:25, Cary Coutant wrote:
David,
As part of this, we rearrange
the references from
`DW_FORM_implicit_const`, `DW_FORM_addrx`, and `DW_FORM_indirect`
to be listed in the order
`DW_FORM_addrx`, `DW_FORM_implicit_const`, and `DW_FORM_indirect`.
`DW_FORM_addrx`
David,
As part of this, we rearrange
> the references from
> `DW_FORM_implicit_const`, `DW_FORM_addrx`, and `DW_FORM_indirect`
> to be listed in the order
> `DW_FORM_addrx`, `DW_FORM_implicit_const`, and `DW_FORM_indirect`.
`DW_FORM_addrx` is not part of the proposal so
> we keep it separate (ju
On Wed, Apr 23, 2025 at 8:45 AM Michael Buch wrote:
>
> Sounds like this is what
> https://github.com/llvm/llvm-project/pull/130255 is trying to achieve?
Yes, though that may be trying to achieve other things too (there's
some discussion of trying to go from the class definition in the DWARF
to t
Consider the following C++ program
#include
class Base {
public:
virtual const char* method1() = 0;
void method2() {
printf("%s\n", method1());
}
};
class DerivedOne : public Base {
virtual const char* method1() override {
return "DerivedOne";
}
};
template
class DerivedTwo :
Sounds like this is what
https://github.com/llvm/llvm-project/pull/130255 is trying to achieve?
If we could simplify that part of LLDB that'd be great!
On Wed, 23 Apr 2025 at 16:32, Kyle Huey via Dwarf-discuss
wrote:
>
> Consider the following C++ program
>
> #include
>
> class Base {
> public:
12 matches
Mail list logo
