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