Hey, >> [...] but it matters with my patch: if you initialise libunwind with address >> in kernel signal trampoline itself, then ask unw_is_signal_frame(), you'll >> get "no", incorrectly. [...] > > ah, yes; looking at one of the earliest e-mails where it was suggested > adding is_interrupted: > > <signal> is_interrupted=1 is_signal=1 -- inner > handler() is_interrupted=1 is_signal=0 > <signal> is_interrupted=0 is_signal=1 > foo() is_interrupted=1 is_signal=0 > main() is_interrupted=0 is_signal=0 -- outer > > then it may not be an issue. Here "use_prev_insn" === ! is_interrupted.
Yes. > Sounds right; the inner most frame, for ptrace, was interrupted and > therefore, use_prev_instr would be false. Glad to hear that part went right. > Having "is_signal_frame" wrong for the inner most frame would lead to > back-trace code that relied on it not displaying something like > <signal-trampoline> for that frame. A user would notice, for > instance, that when stepping out-of a handler and into the > signal-trampoline, that the trampoline frame's name confusingly > changes. Correct. > However, perhaps the thing to do here is accept, document, and even > deprecate is_signal_frame since it isn't reliable. Instead, > reflecting the underlying implementation's need to do a step to the > caller and add a flag - along the lines of use_prev_instr or > is_interrupted - to indicate the state of the callee. > > thoughts? I'll let those with more experience speak. For our purposes a signal frame is just another frame and I am unfamiliar with libunwind uses which care about the distinction. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
