[Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[Ron Louzon via Dwarf-Discuss]

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.  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?
thanks,ron___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[Robinson, Paul via Dwarf-Discuss]

DW_AT_artificial generally means the item is compiler-generated, or otherwise 
has no explicit representation in the source.
An artificial member in a structure takes up however much space it takes, just 
like any other member, and the compiler should have generated the correct 
offsets for the other members of the structure.  So, I’d expect the first 
non-artificial member to have offset 4 (or greater).  Whether the consumer (in 
this case, your application) has to compensate really depends on what the 
application is doing.
--paulr

From: Dwarf-Discuss  On Behalf Of Ron 
Louzon via Dwarf-Discuss
Sent: Monday, February 28, 2022 8:50 AM
To: Dwarf-Discuss@lists.dwarfstd.org
Subject: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

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

thanks,
ron
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[Greg Clayton via Dwarf-Discuss]

> On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss 
>  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 structure. 

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



> 
> thanks,
> ron
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[David Blaikie via Dwarf-Discuss]

On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

>
>
> On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss <
> dwarf-discuss@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
> structure.
>
>
> 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
> variable.
>

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.
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[Greg Clayton via Dwarf-Discuss]

> On Feb 28, 2022, at 1:11 PM, David Blaikie via Dwarf-Discuss 
>  wrote:
> 
> 
> 
> On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss 
> mailto:dwarf-discuss@lists.dwarfstd.org>> 
> wrote:
> 
> 
>> On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss 
>> mailto:dwarf-discuss@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 structure. 
> 
> 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 variable.
> 
> 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.

Sounds interesting, yes. Maybe a DW_AT_language_runtime attribute? This could 
let people know that the item is part of the language runtime and not 
necessarily something the user would always want to see.

> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org 
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org 
> 
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] How to interpret DW_AT_artificial tag?

[Michael Eager via Dwarf-Discuss]

On 2/28/22 13:11, David Blaikie via Dwarf-Discuss wrote:
On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss 
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.


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.


This is a peculiarity of C++ where an artificial variable has a user-
accessible name.  Rather than have a special attribute to distinguish
this oddity, and since "this" is a reserved word in C++, it seems
easiest to simply check for this special case if the language is C++.
You can reasonably hard-code "this" knowing it can't be used for any
other purpose.  You cannot say the same about vtable pointers which can
have any (or no) name.

--
Michael Eager
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org