This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consensus on MT-, AS- and AC-Safety docs.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]