This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: release soonish
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 25 Jan 2012 00:41:25 +0100
- Subject: Re: release soonish
On Mon, Jan 23, 2012 at 11:00:43AM -0800, Roland McGrath wrote:
> I'm somewhat ambivalent about the API. I don't really like reading a
> section offset as if it were an uninterpreted integer. OTOH, it does seem
> useful to have a low-level interface for getting such an offset, and at
> that level it is close to be an uninterpreted integer. It's unfortunate
> that they overloaded a single form instead of going with per-target-section
> forms: it means a low-level accessor has no way to validate the datum.
Yes, but this isn't different from the old DW_FORM_data4/8. And in a lot
of cases you do need to know which attribute you are using to validate
or interpret form data.
> Since these used to use the data forms before DWARF 3, I can't really
> decide whether it is a good convenience to let you read them that way,
> or it's propagating a bad overloading.
The documentation of dwarf_formudata () says:
/* Return unsigned constant represented by attribute. */
which I interpreted as "give me the form data as if it is an unsigned
constant, I know that it is one in this context".
> As to the implementation, it can't use __libdw_read_address. It needs to
> be __libdw_read_offset or at least something using __libdw_relocate_offset.
> Otherwise it won't do the relocation handling the right way whenever we
> switch that stuff on.
Are you sure? For DW_FORM_data4/8 we already use __libdw_read_address.
I might be missing something, but that seems correct because it uses
the relocation handling hooks already. If that wasn't correct the previous
workaround for reading DW_FORM_sec_offset by tweaking the Dwarf_Attribute
form field (setting it to data4/8) was also incorrect. Is it?
Thanks,
Mark