Re: Support for i386 builds of glibc?

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Mar 04, 2013 at 06:10:40PM -0500, David Miller wrote:
> From: "Maciej W. Rozycki" <macro@codesourcery.com>
> Date: Mon, 4 Mar 2013 23:03:11 +0000
> 
> > On Mon, 4 Mar 2013, David Miller wrote:
> > 
> >> >  I think "can't" is too strong a statement, signals are to userland what 
> >> > interrupts are to the kernel.  The whole critical section could run with 
> >> > all signals blocked; if you wrote that the overhead might be prohibitive, 
> >> > then I would agree though.
> >> 
> >> You can't mess with signal state in the lock handlers, think about
> >> siglongjmp and friends.
> >> 
> >> It's impossible even if you're willing to accept prohibitive cost.
> > 
> >  I don't believe it.  Can you provide me with an example where a sequence 
> > like:
> 
> Yep, that would seemingly work.
> 
> Next, what if the manual cmpxchg faults and the signal handler
> wants to take this lock to report the SIGSEGV to the user?

Too bad. There's no requirement/guarantee that invoking undefined
behavior gives you SIGSEGV. In this case, SIGSEGV would be blocked at
the time of the fault, which, if I remember correctly, results in
either deadlock or process termination. Maybe not the ideal result
from a debugging standpoint, but a perfectly valid and conforming
implementation nonetheless.

By the way, the extremely slow strategy described here is a general
solution to making non-async-signal-safe operations async-signal-safe.
It's the modern userspace equivalent of CLI/STI in kernelspace (or on
DOS/realmode)...

Rich