[Dwarf-Discuss] How to interpret DW_AT_artificial tag?
dblaikie at gmail.com
Mon Feb 28 13:11:02 PST 2022
On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:
> On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss <
> dwarf-discuss at lists.dwarfstd.org> wrote:
> 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
> This will cause all other members to be pushed out by a pointer size.
> 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?
> 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.
> 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
Probably the important distinction there is that "this", while artificial,
is named/usable in the source whereas the vtable isn't.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dwarf-Discuss