Re: Saving errno around signal handlers

[Rich Felker <dalias at aerifal dot cx>]

On Fri, Feb 28, 2014 at 12:49:45PM +0100, Florian Weimer wrote:
> POSIX has green-lighted saving errno around signal handlers.  So the
> question now is how we implement that.
> 
> * glibc-only solution
> 
> We need to wrap the signal handler with a function that calls the
> actual handler, saving and restoring errno around it.  We do not
> have a place to store the real handler address, so we need to use
> separate trampolines, either generated dynamically or a from a
> static, pre-allocated pool.  There are only a few signal handlers,
> so a static set of trampolines would work if we deallocate
> trampolines.

This is nonsense. You only need one "trampoline". The signal number is
the first argument to the signal handler, so it (the one trampoline)
can simply lookup the real signal handler to run in a static array of
function pointers based on its first argument.

> The problem with deallocation is that when sigaction is used to
> obtain the address of the existing handler, we have to translate it
> back, and concurrently freeing the trampoline will result in the
> wrong handler address.  So we'd need some form of locking, and it
> still needs to be fully reentrant, so this will be difficult.

No translation is necessary. You just read back the function pointer
from the static array in userspace. The locking however is somewhat
painful. I think sigaction would need to block all signals then
acquire the lock with signals blocked to preserve its own
async-signal-safety.

Of course I don't see why you even want to do this. The direction
POSIX is taking is to require applications to save and restore errno
if they might clobber it in the signal handler. There is no reason to
introduce lots of complexity, overhead, and runtime latency to signal
handling in glibc to accommodate programs which do not follow this
requirement.

Rich