Re: release soonish

[Roland McGrath <roland at hack dot frob dot com>]

> 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. 

I didn't quite say that.  I do think there are precious few good reasons
for wanting to see such an offset as an integer.  But if you are really
writing something that is concerned with the lowest levels of encoding,
then perhaps it is what you want.  (For anything interesting, I think you
really just want to look at the referenced information semantically.)

dwarf_formudata could be it.  My suggestion was that it could handle it,
with smarts to know which section it referred to so it can validate the
offset (and handle relocation with pedantic correctness).

> 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.

Get out of the Wayback Machine, Mark.  We're talking about 0.153 now.

As I said before and just reiterated above, dwarf_formudata could be OK for
the low-level access if we make it appropriately smart.  I don't think it
makes sense to consider anything about "sec_offset" to be "higher-level".
The only things that are actually higher-level are interfaces that are
about getting the information the attribute points to, not the
encoding-level detail of a section offset.  We already have such interfaces
for the various kinds of things pointed to, and can add more at that level
for whatever is missing.

> 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).

I think you are misunderstanding the meaning of the arguments to
__libdw_read_address.  The check against SEC_INDEX is verifying that the
attribute data pointer is valid--that's always a pointer into the CU
section.  There are no checks on the value extracted.

> 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.

I'd like to make it consistent now.  The smarts will validate that it's an
attribute expected to hold a section offset, and that the offset is valid
for its target section.


Thanks,
Roland