Re: signal unwind and fp state

[Ian Lance Taylor <iant at google dot com>]

Roman Zippel <zippel@linux-m68k.org> writes:

> While working on a vdso for Linux/m68k I stumbled again on a problem, I 
> already had with the fallback unwind handler in gcc, where I'd like to 
> hear some opinions.
> I'm looking at the i386 unwind handler and that doesn't bother to restore 
> any fp registers. On m68k it's a little more difficult as the fp register 
> are saved/restored conditionally. There are also a few fp control register 
> on the stack, which are currently not restored via unwind.
> 
> The question maybe here is what really needs to restored via the signal 
> frame? If it's only for exception handling call clobbered registers 
> wouldn't really need to be restored (often they are even immediately 
> overwritten again to setup the exception handler) and even call saved 
> register don't really need to restored as that should already be done via 
> the frame of the signal handler itself (and depends on SA_SIGINFO anyway).
> 
> So is there really any need to restore in the signal frame more than 
> return address and frame address? AFAICT that should be enough for 
> exception handling, but maybe there is something else...

I don't know the answer.  But I do know that you need to think about
-fasynchronous-unwind-tables, and you need to think about how your
kernel handles registers when calling a handler, and you need to think
about what unwind information is available in the kernel, if any.  If
the kernel does not provide unwind information showing that the signal
handling call restores registers, then it seems to me that the stack
unwinder needs to restore at least all caller saved registers from the
signal frame.  Whether it needs to restore the floating point
registers depends upon whether the kernel can ever modify those
registers.

Ian