Hi, > It's actually a little messier even than that, because the whole thing > about backing up one call instruction only makes sense for regular > stack frames. A signal handler should not back up any instructions. > (We ran into a related but different problem recently -- see > https://bugzilla.mozilla.org/show_bug.cgi?id=695985 ).
We actually know the state inside libunwind, it's dwarf_cursor's use_prev_instr. If set we subtract one from the IP before use (= call), if zero we use IP as-is (= signal, etc.). Indeed you have to be very careful not to look after the call instruction - doing so does result in bad unwind decisions in real life. It's not unusual for compiler to place 'call' as a last instruction in a function (and thus FDE), or for the very next instruction to push/pop stack. There's unw_is_signal_frame() to return the info, sort of. There isn't an API to retrieve use_prev_instr as such that I know of. The fast trace code (= unw_backtrace()) accounts for use_prev_instr to adjust the IP addresses it reports. For other unwind methods you can use unw_is_signal_frame() instead and subtract one from returned IP if it returns zero. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
