Re: [Libunwind-devel] [PATCH 0/8] libunwind accuracy improvements for x86-64

[Lassi Tuura]

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