Re: Some elfutils/libdw/cfi comments

[Roland McGrath <roland at redhat dot com>]

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

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

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

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

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.


Thanks,
Roland