<div dir="ltr"><div>Pulling out part of my reply from the previous thread to focus on the first of the three parts, <a href="https://dwarfstd.org/issues/250506.1.html">250506.1</a></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, May 13, 2025 at 8:05 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>(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?)<br><br>(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 interest from LLDB & some perspective on GDB provided by Tom Tromey and much appreciated: <a href="https://github.com/llvm/llvm-project/pull/130255" target="_blank">https://github.com/llvm/llvm-project/pull/130255</a> )<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 6, 2025 at 6:20 PM Cary Coutant via Dwarf-discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">I've written a three-part proposal to address these issues:</span></div><div><ul><li><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">The first part,<span> </span></span><a href="https://dwarfstd.org/issues/250506.1.html" style="font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif" target="_blank">250506.1</a><span style="color:rgb(0,0,0);font-family:"Nunito Sans","Lucida Grande","Lucida Sans Unicode","Lucida Sans",Lucida,sans-serif;font-size:medium">, proposes a standard mechanism for locating the virtual function table (vtable) given an object of a polymorphic class.</span></li></ul></div></div></div></blockquote><div>The proposed mechanism is a single attribute on the type with the location description of the vtable (given a pointer to the object), yeah? I wouldn't think this would address one of the discussed/requested needs, which is to know where/how much space it takes up in the layout/that the gap is not padding, right? If you wanted to know the layout, you'd have to partially evaluate the expression to get to the pointer - whereas the expression when fully evaluated would give you the vtable itself, having passed through the vtable pointer already.<br>Is there a use case where there isn't a vtable pointer in the layout that can be described like another member? (admittedly encoding a member takes more bytes of DWARF than a single location attribute)</div></div></div></blockquote><div><br> Reiterating here that this solution doesn't address the petitioners point (1) about structure layout/identifying the vtable pointer bytes in the object representation.<br><br>Any way we could verify (presumably the original GCC bug reporter from 20 years ago isn't interested in this anymore - but maybe they are?) whether that use case is important? I'm sort of of the opinion that it isn't - DWARF consumers shouldn't care how the layout came to be, they should just consume it.<br><br>but equally - if the vtable pointer is effectively an unnamed member (I'd say it is) - maybe it's simpler for consumers to model it as such?<br><br><br>Separately, we discussed in the last meeting where this DW_AT_vtable_location should be used.<br><br>I think the DWARF spec is sufficiently vague/non-prescriptive that we maybe don't need to say anything about this. We just say it can be used and its up to implementations to choose how to use it?<br><br>But if we want some non-normative text, I'd say we suggest its use on any type that defines a vtable pointer artificial member. (might be easier/obvious/not need to be said if we modeled it as an artificial member instead, though)</div></div></div>