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 _______________________________________________ elfutils-devel mailing list elfutils-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/elfutils-devel
