Thanks for the responses. We have mission critical airborne real-time
processors and we have tools which use the DWARF information to locate and
monitor variables while the processors are running. Our tools generate memory
addresses of the variables to be monitored and when addressing certain
structures, these DW_AT_artifical members will cause the actual structure
members to move in memory. Your responses have verified what I thought I was
seeing in the DWARF information. Thanks again. - ron
On Monday, February 28, 2022, 09:01:39 AM EST, Robinson, Paul
<[email protected]> wrote:
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 <[email protected]>On Behalf Of Ron
Louzon via Dwarf-Discuss
Sent: Monday, February 28, 2022 8:50 AM
To: [email protected]
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
[email protected]
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
