[Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?

Ron Louzon louzonr at yahoo.com
Thu Oct 6 05:04:43 PDT 2011

I didn't know about the dwarf_get_form_class() function.  I was looking at the attribute's form type which essentially gives me the same information but dwarf_get_form_class() will make the job cleaner.  
I need to maintain a location description list for variables. As I drill down through pointers to objects and then to the object members which may themselves be pointers to objects, I am required to build a location description list which describes the address of a member.  Once the pointer values are retrieved, I then fill in the holes in the location description list and generate a physical address.  This means that I must convert the constant member offset into a location description which I add to my list.  It would have been easier for me if, when it encountered a constant,  the dwarf_loclist_n() function returned a location description which was essentially an add operand and the constant value.
Again, thanks for explaining the DWARF 4 changes.
- Ron

From: David Anderson <davea42 at earthlink.net>
To: Ron Louzon <louzonr at yahoo.com>
Sent: Wednesday, October 5, 2011 5:04 PM
Subject: Re: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?

On 10/04/2011 12:34 PM, Ron Louzon wrote:
> Since dwarf_loclist_n() already supports DW_FORM_data4 and DW_FORM_data8, i s there any plan to update it in a future release to accomodate DW_FORM_sdata?
> Thanks for the help with this.
> - Ron
> *From:* David Anderson <davea42 at earthlink.net>
> *To:* dwarf-discuss at lists.dwarfstd.org
> *Sent:* Tuesday, October 4, 2011 3:08 PM
> *Subject:* Re: [Dwarf-Discuss] Attribute DW_AT_location has form DW_FORM_sdata?
> On 10/04/2011 11:03 AM, Ron Louzon wrote:
> >
> > In the past, when dealing with structure and class members, I have always been able to use the dwarf_loclist() and dwarf_loclist_n() functions to retrieve location information for the members.  These functions would return the offset which was applicable for whatever member was being examined.  With the GNU 4.4 compiler, these functions are returning an error because the DW_AT_data_member_location attribute is of the form DW_FORM_sdata and these functions do not handle that attribute form.
> > I have never encountered this before.  I can deal with this by reading the data as a signed number but is this normal?  Do I always need to examine the form type to determine how to deal with a DW_AT_data_member_location attribute or is this a special case due to abnormal output from the GNU 4.4 compiler?
> >
> I added support  (June 2011 I think) to dwarfdump
> for an arbitrary constant as the value of DW_AT_data_member_location
> and I seem to recall this was exactly because of gcc and DW_FORM_sdata on
> DW_AT_data_member_location.    The signed constant kind of surprised me too.

Ron, I have a real test case with the issue you bring up, on with DW_AT_data_member_location
being  DW_FORM_sdata..
The decision of whether to call dwarf_loclist_n(),
or to just accept a constant for DW_AT_data_member_location,
is a choice that is made outside of dwarf_loclist_n().

dwarf_loclist_n() is for location lists, but a DWARF4 constant for DW_AT_data_member_location
means 'do not call dwarf_loclist_n() as there is no loclist here'.  If you take a look at
            fc = dwarf_get_form_class(version,attr,offset_size,theform);
            if(fc == DW_FORM_CLASS_CONSTANT) {

is how dwarfdump deals with this sort of thing.

Maybe I am misunderstanding your point here.
Do you have a testcase executable or object you can send me (to include in the
libdwarf/dwarfdump tests)? One that gives you trouble?


-- I have a rock garden. Last week three of them died. -- Richard Diran

dwarf-discuss at lists.dwarfstd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20111006/5767d4c3/attachment-0002.htm>

More information about the Dwarf-Discuss mailing list