On Thu, 2010-06-17 at 11:58 -0700, Roland McGrath wrote: > > I am not completely clear on why the encoding is given as udata4/8 > > instead of the actual encoding in use. While it is useful to ensure that > > the addresses used are all sane according to the arch used. But it seems > > more useful to have the actual encoding (also). > > You do have the actual encoding information, just not the actual encoding > byte. I added the canonicalization because in the v4 format (not actually > generated anywhere, but now supported in libdw), there is a CIE header > field for address_size. So this tells you what DW_EH_PH_absptr (i.e. the > default encoding in the absence of .eh_frame-style "R" augmentation) > actually means, which is otherwise ambiguous when the CIE might be v4 > format.
I might be missing something, but in case the is a "R" augmentation in the CIE, and I only have udata4/8, it seems I am unable to figure out whether the addresses are pc/text/data/func encoded. > > The reason I like to know the actual encoding is because then I can > > decide whether or not using an FDE might require extra pointer decoding > > or not. > > I don't follow. This is exactly why you need to know the actual encoding > in use in an unambiguous way, rather than the actual encoding byte in the > header, whose meaning can depend on the address_size header field. Don't I need both then? > > One use case that isn't easily possible with this interface is rewriting > > the FDEs/CIEs. For example for filtering out duplicate CIEs, or > > reencoding the address encoding used. > > What do you have in mind for that? If you had an offset to pass to > dwarf_cfi_validate_fde, then you must have gotten that by iterating through > with dwarf_next_cfi. So you had Dwarf_FDE.CIE_pointer on hand when you > made the call. Yes, I have the CIE_pointer, but I might not yet have seen that CIE, since (theoretically, I never seen it in practice) it might be after the FDE we are currently inspecting. > > If that is not out of scope, then for that it would be nice to also get > > the actual Dwarf_CIE referenced by the FDE (so the caller doesn't have > > to cache that themselves), and having the FDE augmentation and > > instructions data pointers plus sizes being returned by the function. > > Ok. What exactly do you mean by returning the augmentation et al? Looking at the (eh_frame) FDE definition from: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html and FDE can have its own augmentation data, which can describe the LSDA. Looking at libdw intern_fde it seems this data is always just discarded? > Do you really want a call that takes an FDE offset at all? It sounds like > you actually just want an iterator through all FDEs that yields all this info. That would also be fine, but it seems that using the offset from dwarf_next_cfi() is that iterator (when ! dwarf_cfi_cie_p). Thanks, Mark _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
