Re: release soonish

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

> Yes, but this isn't different from the old DW_FORM_data4/8.

It's different in that with DW_FORM_data* you can't do any better because
you have zero information about what the meaning of the integer is.  With
DW_FORM_sec_offset, we know it has to be an offset into some DWARF section.

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.

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

Well, that doesn't mean you can read DW_FORM_addr or DW_FORM_strp or
DW_FORM_ref* this way.  It means the attribute should have one of the
DW_FORM_*data* forms, and you want to treat its value as unsigned.

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


Thanks,
Roland