This is the mail archive of the
mailing list for the glibc project.
Re: Support for i386 builds of glibc?
On Mon, Mar 04, 2013 at 06:10:40PM -0500, David Miller wrote:
> From: "Maciej W. Rozycki" <email@example.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
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