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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
