Re: Some elfutils/libdw/cfi comments

[Mark Wielaard <mjw at redhat dot com>]

On Thu, 2010-06-17 at 14:58 -0700, Roland McGrath wrote:
> > 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.
> 
> No, no, no.  Only the low bits get canonicalized from absptr to udata[48].
> The low nibble is "FDE data encoding", the high nibble is "FDE flags".

OK, great. Thanks for clearing that up.

> > > 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?
> 
> Huh?  What dwarf_cfi_validate_fde has told you is exactly how to decode the
> data.  What do you need to know the R augmentation byte for?

I don't, since I have all information. See above, I didn't realize only
the absptr bit got reencoded.

> > 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.
> 
> I did see that in practice somewhere.  Right, but it's a direct pointer, so
> you can decode its header with a dwarf_next_cfi call right then.

Ah, right, yes I can just do that. Thanks.

> > That would also be fine, but it seems that using the offset from
> > dwarf_next_cfi() is that iterator (when ! dwarf_cfi_cie_p).
> 
> Well, yes, but it's repetitive since libdw repeats that call for its
> interning.  And you probably don't care about iterating on CIEs per se.  If
> there are unreferenced CIEs, so what?  You just want to transcode whatever
> the FDEs point to.

Yes, that was my main purpose. Going over the CIEs also and having
access to all the bits in the CIEs/FDEs for reencoding/rewriting them
fully was not immediately necessary, but could come in handy later.

> Sigh.  I was trying to give you a reasonably clean quick hack that we could
> tie up this week to slightly simplify your whole crazy task.  But now we
> are discussing things on the slippery slope to all the compression and
> transcoding work for CFI that I'd vaguely envisioned for the long term.

Sorry about that. It is interesting stuff though. And will be useful for
systemtap later too.

> But I'd thought of doing that in a much different way than the
> half-measures you are doing here, where you are just validating and copying
> the data.

If you feel the current dwarf_cfi_validate_fde () addition is too hacky,
please don't support it. I do think it is useful though, even if it
might be a bit restricted/inefficient going over all FDEs with it. It
would help me clean up a bit of the systemtap translator code, even if
it won't allow me to do full fancy rewrites.

Having a full cfi compression and transcoding framework would be cool,
but might indeed be much more work. Maybe one day we will have the time.
It does sound fun.

Cheers,

Mark