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