Re: Some elfutils/libdw/cfi comments

[Mark Wielaard <mjw at redhat dot com>]

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