Saving errno around signal handlers
Rich Felker
dalias@aerifal.cx
Mon Mar 3 22:19:00 GMT 2014
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
More information about the Libc-alpha
mailing list