Re: determine whether code is running in a signal handler context

[Yubin Ruan <ablacktshirt at gmail dot com>]

2017-10-19 11:12 GMT+08:00 Carlos O'Donell <carlos@redhat.com>:
> On 10/18/2017 07:39 PM, Will Hawkins wrote:
>>> This is not true. It is architecture dependent. For examples on how complex
>>> it is to get this 100% right you have to go read gdb sources to see how
>>> they do this. It is non-trivial. It might be easier to use a library like
>>> libunwind to determine this for you (if it even can).
>>
>> This is a fascinating thread. The downside to using libunwind is that,
>> iirc, it requires debugging information in the binary to work. In other
>> words, it would not work on a stripped binary. Please correct me if I am
>> wrong.
>
> No. libunwind only needs .eh_frame/.debug_frame, not debug information.
>
> Some unwinders can operate without debug information, but only if the
> architecture, and ABI layout of the frame allow unwinding with a frame
> pointer. On 32-bit ARM, at least for a while, the frame pointer was
> synthesized by the compiler to avoid using a fixed frame pointer and
> free up such a pointer for the compiler to use. The side effect is that
> you always need the DWARF unwind information to unwind a frame, but you
> do *not* need debug information. One should be careful not to confuse
> the two. The generic term "debug information" can mean a lot more,
> including all the DWARF required to debug the program. You don't need
> this to unwind, you only need .eh_frame/.debug_frame. As you see 32-bit
> ARM was leading the charge here to free up a register for compiler use,
> and now it's common practice on x86_64 and x86 to compile without the
> frame pointer, and so you must have auxiliary information to unwind,
> and you can't write a by-hand unwinder that follows the frame pointer.

By "auxiliary information", do you mean those auxiliary information
provided by the kernel (to the dynamic loader), e.g., environment
variables, or what? It seems to me that if we have the frame pointers,
it would be a lot easier. And it would be better if we limit our code
to X86/64.

> The complex part is that to unwind from an asynchronously delivered signal
> you need asynchronous unwind tables which describe how to unwind from
> any point in the program, because when the signal arrives you may attempt
> an unwind from any point to an outer frame. Usually the unwind information
> can be elided to the point at which function calls are made, or try/catch
> blocks.

Agree. That is why I think checking the stack "by hand" for addresses
in VDSO is not deterministic.

> But you need not unwind from the signal handler, you need only detect
> that you are *in* a signal handler, and libunwind might have enough

Yes. I should have emphasized that I need only detect that the code is
*in* a signal handler, and that is all I want. So if anyone can
provide more info/heuristic about that (just about that) I will be
very thankful.

Yubin

> heuristics for the machines you care about that it might work. I have
> not tried it though, so YMMV.