Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

(hopefully this doesn't get too lost in all the other discussion in this thread - maybe best to spin things out under separate subject lines/subthreads?) (I'm looking into this more in the context of LLVM trying to solve the downcasting part of this, motivated by Sony's SCE debugger but also with

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

> > In 250506.2, the use of a rnglist is throwing me. I would expect the > lifetime of a vtable to be the whole program. Or did you envision the > rnglist to be the range of data/rodata addresses of the vtable object? > 2.17 clarifies that they're code addresses (i.e. text), though. > The DW_AT_

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

In 250506.2, the use of a rnglist is throwing me. I would expect the lifetime of a vtable to be the whole program. Or did you envision the rnglist to be the range of data/rodata addresses of the vtable object? 2.17 clarifies that they're code addresses (i.e. text), though. We did have a disc

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

On Wed, May 7, 2025 at 4:11 PM Todd Allen wrote: > I think that's orthogonal to the point, which was that a rnglist is > meant to describe a pc range, not a data range. Got it; I did not get this was your point, I was mainly reacting to the part of your message “I would expect the lifetime of a v

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

I think that's orthogonal to the point, which was that a rnglist is meant to describe a pc range, not a data range. BTW, I don't think you need to create the vtable on the fly in that case.  The Pkg.Print function will need a static link, but the vtable doesn't need to encode that.  I just chec

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

Hello, On Wed, May 7, 2025 at 2:49 PM Todd Allen via Dwarf-discuss wrote: > In 250506.2, the use of a rnglist is throwing me. I would expect the > lifetime of a vtable to be the whole program. Or did you envision the > rnglist to be the range of data/rodata addresses of the vtable object? 2.

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

Can unions have virtual functions and thus vtables? My understanding is that unions can have member functions but I can't see how they can have virtual functions? What function would you call? Where would you put the vtable pointer? This article on C++ reference suggests that they cannot have

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

I've written a three-part proposal to address these issues: - The first part, 250506.1 , proposes a standard mechanism for locating the virtual function table (vtable) given an object of a polymorphic class. - The second part, 250506.2

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

FWIW, when we at Concurrent were in the compiler business, our C++ compilers generated two vendor-defined attributes, both hanging off the DW_TAG_{structure,class}_type. Here are a couple with some sample locations: DW_AT_vtable_location [DW_OP_plus_uconst 0; DW_OP_deref] DW_AT_type_vtable_locat

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

Hi all, The LLVM discussion linked [0] happens to be us Sony folks, and it's supporting the use-case Kyle described of automatic downcasting, i.e. identifying the most-derived-class of an object from its vtable pointer. Having to demangle the symbol table is a real pain (Tom, CC'd knows more) espe

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

> > Actually, for GCC and LLVM, the location is an *index* into vtable, *not* > an offset. We have a compiler abstraction that knows how to convert the > DWARF DW_AT_vtable_elem_location to our internal representation of a > location, because various compilers generate the DWARF differently and the

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

On 4/23/25 22:46, Cary Coutant via Dwarf-discuss wrote: Looking at the DWARF generated by GCC (and I'm guessing LLVM does the same), I see vtable_elem_location attributes that look like this: <1b8> DW_AT_vtable_elem_location: 2 byte block: 10 0 (DW_OP_constu: 0) This is not correct DWARF!

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

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

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

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

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

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

[Dwarf-discuss] Representing vtables in DWARF for downcasting

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 :

Re: [Dwarf-discuss] Representing vtables in DWARF for downcasting

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: