In message <20040514151957.GA599@drowsy.duskware.de>, you write: 

-> On Fri, May 14, 2004 at 11:01:21AM -0400, Rafal Boni wrote:
-> > Maybe interestingly, regress/lib/libpthread/siglongjmp1 fails with:
-> > 
-> > 	./siglongjmp1
-> > 	siglongjmp1: SIGSEGV set
-> 
-> This usually happens when some libc stub (like __setjmp14) directly calls
-> a weak aliased system call (like sigprocmask). This way the sigprocmask
-> inside the kernel changes but libpthreads idea of it does not.

Unfortunately, that doesn't seem to be the case here...

-> Unfortunately on RISC machines it's often far more easy to do a system
-> call than to do a PIC call to a libc stub which does the system call -
-> but we must do the latter.

Heh, it's not nearly as bad on mips as as sparc64 (at least from looking
at the sparc64 version of the file :-).

-> Not that I've looked at the mips libc code at all, just reporting from my
-> experience - been there, had that wrong too - thanks to Christian Limpach 
-> for diagnostic help. Hmm, but then I think Simon and I talked about this
-> failure mode when he did the libc changes - could this be a ld.elf_so
-> problem?

I was wondering that myself because of other symptoms (like attaching gdb
and setting a breakpt in the process that caused the kernel to fall over
let the process run fine after continuing, whereas without the breakpt,
the kernel would go *boom*).

Thanks,
--rafal

----
Rafal Boni                                                     rafal@pobox.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill