Re: release soonish

[Mark Wielaard <mjw at redhat dot com>]

On Thu, 2012-01-26 at 13:53 -0800, Roland McGrath wrote:
> Hence it becomes reasonable to consider an API wherein you have to say
> which section it refers to.  It would be a no-brainer if IDX_* were part of
> the public API.  (Frankly IMHO it's a no-brainer that when DWARF introduced
> DW_FORM_sec_offset they should have added the ten distinct forms for the
> different target sections, it's not like we're really in danger of running
> out of form codes.  But they didn't ask me.)
>
> > And in a lot of cases you do need to know which attribute you are using
> > to validate or interpret form data.
> 
> That's certainly true.  Sometimes that might mean that the API should
> require that knowledge of its caller.  The IDX_* values aren't part of the
> API and I don't think we want them to be.  But we can use DW_AT_* constants
> as proxies--and we already know the one in question in this interface.  So
> without even changing the API, we can make this call smart about use of
> DW_FORM_sec_offset.  We just need some more internal knowledge about which
> attributes refer to which sections.

OK, so you don't want a low level interface that just gives you the
offset as an index, but want an interface that explicitly ties it to a
target section? Then using dwarf_formudata () would not be it. That is a
pity though since that means you cannot do some things with an attribute
depending on whether its value is encoded as a DW_FORM_data4/8 or
DW_FORM_sec_offset. That was really why I just wanted the simple
addition of DW_FORM_sec_offset decoding added to dwarf_formudata ().

Can't we have both? dwarf_formudata () for low-level access and a new
dwarf_formsec_off() as a higher level api? The later in some future
elfutils release after 0.138 of course.

> > > 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?
> 
> address!=offset.  This is all moot in the trunk, since they're both no-ops.
> But in the roland/relocate branch you'll see the difference.  The kinds of
> relocs that are valid for an address are different from those for an offset.

I see, on the relocate branch the current usage of __libdw_read_address
for DW_FORM_data4/8 is also wrong since it will do an additional check
of whether the return value is within the data of the target section
(which the current dwarf_formudata unconditionally sets to cu_sec_idx).
So we will need more smarts, using the given Dwarf_Attribute, to make it
work against the relocate branch. But do we need to do this now? Can't
we for the 0.138 release just handle DW_FORM_sec_offset in
dwarf_formudata () like we handle DW_FORM_data4/8? Then for a future
release when we introduce a new high-level function and/or integrate the
relocate branch we can fix it up for all forms.

Thanks,

Mark