Re: Saving errno around signal handlers

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Mar 03, 2014 at 09:57:59AM +0100, Florian Weimer wrote:
> On 02/28/2014 11:16 PM, Joseph S. Myers wrote:
> >On Fri, 28 Feb 2014, Richard Henderson wrote:
> >
> >>I'll note that this *may* affect other tools, that have previously looked
> >>through trampolines via code inspection.
> >
> >I don't know if the comment in sysdeps/unix/sysv/linux/mips/sigaction.c is
> >still accurate:
> >
> >/* NOTE: Please think twice before making any changes to the bits of
> >    code below.  GDB needs some intimate knowledge about it to
> >    recognize them as signal trampolines, and make backtraces through
> >    signal handlers work right.  Important are both the names
> >    (__restore_rt) and the exact instruction sequence.
> >    If you ever feel the need to make any changes, please notify the
> >    appropriate GDB maintainer.  */
> >
> >(<https://sourceware.org/glibc/wiki/Development_Todo/Master#MIPS> points
> >to a summary of known MIPS cases of CFI information missing in assembly
> >sources, which includes this one.)
> 
> If we're fine with showing another stack frame in the backtrace of
> signal handlers, we could just avoid the fancy tail call and not
> change the restorer function at all.  Then, from GDB's point of
> view, the signal handler is the glibc-provided wrapper (which
> obviously needs proper unwinding information etc.), and the
> user-installed handler is just some function called from a signal
> handler.

I highly prefer this approach since SA_RESTORER is officially
deprecated by the kernel folks and not even supported for new archs,
as far as I can tell (some don't define it or have a member in the
arch-specific sigaction structure for it).

As for Carlos' concern about the extra stack frame, I don't see how
that could break anything. If we're going to worry about that, I think
we should see at least one concrete example of usage that it could
potentially interfere with.

Rich