Stepping out of signal handler problem

Stepping out of signal handler problem

[Aleksandar Ristovski]

Hello,

I have a problem with stepping out of signal handler (on Neutrino OS). 

I am using sigstep (testsuite/gdb.base) test: When breakpoint is hit inside 'handler', and then doing step or stepi, gdb will not stop inside 'main'. 

I have identified the problem, but do not know how to solve it. 

The description of the problem:

After 'handler' returns to signal trampoline, we can properly identify context using current method (retrieving context pointer from EDI register) up to a point where our function restores EDI to state before signal (which is exactly the next stepi away). After this, until the sigreturn kernel call, the context is wrong.

The question 1: how should this (properly) be handled?

I tried to make a static var and keep context pointer until a non-sigtramp frame is identified, but that didn't work either, even with proper context gdb would still not 'land' into the main where it's supposed to, but rather behaves as if 'continue' was given.

This makes question 2: Is the only way to implement this similar to linux-nat (scanning for sigreturn kernel call)? Is there anything 'cleaner'?


Any hint would be appreciated.

Thanks,

Aleksandar Ristovski
QNX Software Systems

Re: Stepping out of signal handler problem

[Mark Kettenis]

> From: Aleksandar Ristovski <aristovski@qnx.com>
> Date:  Fri, 16 May 2008 12:26:43 -0400
>
> This makes question 2: Is the only way to implement this similar to
> linux-nat (scanning for sigreturn kernel call)? Is there anything
> 'cleaner'?

The clean way of doing this is provide proper unwind info for the
signal trampoline.  This shouldn't be too difficult if your signal
trampolines live in libc, and quite a bit harder if they are in the
kernel.

Re: Stepping out of signal handler problem

[Aleksandar Ristovski]

Mark Kettenis wrote:
>> From: Aleksandar Ristovski <aristovski@qnx.com>
>> Date:  Fri, 16 May 2008 12:26:43 -0400
>>
>> This makes question 2: Is the only way to implement this similar to
>> linux-nat (scanning for sigreturn kernel call)? Is there anything
>> 'cleaner'?
> 
> The clean way of doing this is provide proper unwind info for the
> signal trampoline.  This shouldn't be too difficult if your signal
> trampolines live in libc, and quite a bit harder if they are in the
> kernel.
> 

What is the preferred way: frame_unwind_append_sniffer or tramp_frame_prepend_unwinder?
 

Re: Stepping out of signal handler problem

[Mark Kettenis]

> Date: Fri, 16 May 2008 14:48:36 -0400
> From: Aleksandar Ristovski <aristovski@qnx.com>
> 
> Mark Kettenis wrote:
> >> From: Aleksandar Ristovski <aristovski@qnx.com>
> >> Date:  Fri, 16 May 2008 12:26:43 -0400
> >>
> >> This makes question 2: Is the only way to implement this similar to
> >> linux-nat (scanning for sigreturn kernel call)? Is there anything
> >> 'cleaner'?
> > 
> > The clean way of doing this is provide proper unwind info for the
> > signal trampoline.  This shouldn't be too difficult if your signal
> > trampolines live in libc, and quite a bit harder if they are in the
> > kernel.
> > 
> 
> What is the preferred way: frame_unwind_append_sniffer or
> tramp_frame_prepend_unwinder?

Neither.  I was referring to the possibility to generate DWARF2 frame
info for the signal trampoline.  This is what is done in glibc, the
Linux C library.  We also have a test for this in the GDB testsuite
(gdb.arch/i386-signal.c).

The nice thing about this approach is that it avoids hardcoding the
signal frame layout in GDB, making it possible to change the
implementation without having to adjust GDB.