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