This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on MT-, AS- and AC-Safety docs.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>, Torvald Riegel <triegel at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>
- Date: Fri, 29 Nov 2013 10:04:11 -0500
- Subject: Re: Consensus on MT-, AS- and AC-Safety docs.
- Authentication-results: sourceware.org; auth=none
- References: <528A7C8F dot 8060805 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311182312130 dot 8831 at digraph dot polyomino dot org dot uk> <528BA2DA dot 3090608 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311192205550 dot 8742 at digraph dot polyomino dot org dot uk> <20131120204655 dot GL24286 at brightrain dot aerifal dot cx> <5295CD1D dot 7080501 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1311271329590 dot 5027 at digraph dot polyomino dot org dot uk> <5295F7A3 dot 9050209 at redhat dot com> <5298243E dot 5050401 at redhat dot com>
On Fri, Nov 29, 2013 at 12:21:02AM -0500, Carlos O'Donell wrote:
> On 11/27/2013 08:46 AM, Florian Weimer wrote:
> > On 11/27/2013 02:34 PM, Joseph S. Myers wrote:
> >> On Wed, 27 Nov 2013, Florian Weimer wrote:
> >>> I think we should do that in the code that wraps the signal
> >>> handler call, to address this class of errors once and for all.
> >>> Is this feasible?
> >>
> >> On many architectures the signal trampoline is provided by the
> >> kernel and so has no access to libc implementation details like
> >> errno. As far as I understand, even when provided by libc all it
> >> does is call the sigreturn syscall and provide appropriate unwind
> >> information for the registers the kernel saved on the stack - that
> >> is, there is no userspace code called before the signal handler
> >> that would have a chance to save errno.
> >
> > The number of signals is fixed and small, so it should be feasible to
> > install our own handler in the kernel and store the user-supplied
> > handler in a lookup table that gets called from our handler. There
> > might be a slight performance impact, though.
> >
> > But if we think this errno issue is serious, rather than patching
> > almost any signal handler out there right now, we should address it
> > in glibc.
>
> All we need to do is extend the kernel infrastructure to create
> a signal entry trampoline like it does for signal return. This isn't
> impossible, but requires work. The objections are probably about the
> cost of the extra instructions in the entry of the signal handler,
> which I think are invalid given the amount of code that runs in the
> kernel to deliver the signal. Saving errno isn't that much more
> expensive relative to all the other work to deliver the signal.
This would be non-conforming. POSIX permits writing errno from a
signal handler (in fact, it requires all the standard functions to
write to it), and therefore, the code interrupted by the signal
handler can see the changed errno.
Rich