On Thu, 2010-06-17 at 14:58 -0700, Roland McGrath wrote:
> I might be missing something, but in case the is a "R"
> 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.
The low nibble is "FDE data encoding", the high nibble is "FDE
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
> 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
> 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
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
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.