<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">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 style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org" target="_blank">dwarf-discuss@lists.dwarfstd.org</a>> wrote:</div><br><div><div><div style="font-family:verdana,helvetica,sans-serif;font-size:13px"><div dir="ltr">I have an application which uses DwarfLib to extract type information from debug executable images.  I have found in the DWARF data that some structure types have a "virtual" pointer added as their first member and this pointer's DIE contains the tag DW_AT_artificial=true.  How does that pointer member affect the offsets of the members that follow it in the structure. </div></div></div></div></blockquote><div><br></div><div>This will cause all other members to be pushed out by a pointer size.</div><br><blockquote type="cite"><div><div><div style="font-family:verdana,helvetica,sans-serif;font-size:13px"><div dir="ltr"> Should this 4-byte pointer be ignored or will its size cause the other structure members to be pushed out in memory by 4 bytes?</div></div></div></div></blockquote><div><br></div>All offsets in the DWARF should be correct for all members, including artificial members and any members that follow it in memory. So yes, if there is a vtable pointer added as the first member, its offset and all other offsets will be correct, so there is no need to adjust anything when reading this data. </div><div><br></div><div>You could choose to not show this, but I find it is often easier to show this information in case some compiler change in the future marks something that you might want to see as artificial. For example the "this" parameter to C++ methods is marked as artificial, and people do want to see the "this" in the variables view. Granted that is a variable vs a member variable.</div></div></blockquote><div><br>Probably the important distinction there is that "this", while artificial, is named/usable in the source whereas the vtable isn't.<br><br>Either having some DWARF attribute to communicate that distinction, or a workaround might be to detect that the vtable name uses a reserved identifier could be good - I guess the reality is that DWARF consumers probably hardcode some sort of "this is the vtable pointer" -o so maybe we should have some DWARF attribute that communicates that, instead of relying on the string name of the member? Not sure.</div></div></div>