Re: release soonish

[Mark Wielaard <mjw at redhat dot com>]

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