Hi, > I can't think of anything obvious that'd break if we returned a > different answer for UNW_X86_64_CFA. Let me think about this a bit > more before attempting to implement something.
Hm, are you certain about this? The unw_step() output you quoted is on entry to unw_step(). As I understand it, c->dwarf.ip points to the *next* frame's IP address, but c->dwarf.cfa to CFA of the *previous* frame, and then the unw_step()/dwarf_step() performs a sort of an edge transition which leaves c->dwarf.ip again pointing at the next frame or 0 to mark the end. I think c->dwarf.cfa does point to the CFA of the current frame (cf. apply_reg_state()) at the end of the step, but 'current' is a bit strange concept as the state straddles two frames. I think the CFA is correct in that all the dwarf expressions evaluated relative to CFA for that frame are correct. If you ask for CFA after unw_step() it should be returning the right value; I am not sure it returns the right value after unw_getcontext() before first unw_step(). Obviously libunwind callers shouldn't see the state straddling. I'm definitely interested in any thoughts on this, as it will have some impact on the fast trace implementation. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
