In message <20040512082626.14FB723410@thoreau.thistledown.com.au>, you write: 

-> Christopher SEKIYA wrote:
-> 
-> > I think I've isolated the commit that broke it:
-> > 	
-> > 	Module Name:    src
-> > 	Committed By:   simonb
-> > 	Date:           Tue Mar 23 02:21:49 UTC 2004
-> > 
-> > 	Modified Files:
-> > 	        src/lib/libc/arch/mips/gen: __setjmp14.S
-> > 	Added Files:
-> > 	        src/lib/libc/arch/mips/gen: __longjmp14.c
-> > 
-> > 	Log Message:
-> > 	Use setcontext() instead of sigreturn() to implement longjmp().
-> > 
-> > 	cvs rdiff -r0 -r1.1 src/lib/libc/arch/mips/gen/__longjmp14.c
-> > 	cvs rdiff -r1.9 -r1.10 src/lib/libc/arch/mips/gen/__setjmp14.S
-> > 
-> > ... at least, anything built after that commit exhibits the cache panic.
-> 
-> Yay for me :-(  Do any of the regression tests regress/lib/libc/*setjmp*
-> able to reproduce the panic, and if so is it easy to backtrack the kernel
-> to find out when that end of the problem first started occurring?

Not that it really affects anything, but __setjmp14.S also has some bugs
around reorder/noreorder (ie, the explicit zero of v0 in the delay slot
of the __sigprocmask14 call doesn't really happen there) and there are
a few bits I might clean up if I had reason to touch it (put the REG_
EPILOGUE in a saner place, add a nop after the call to abort).

Also, since we have nice SIGCONTEXT_TO_UCONTEXT() macros, shouldn't we
let them do the heavy lifting in __longjmp14.c and only touch up the
fields we explicitly need different?

I've sort-of ran out of ideas, so I'm just picking nits for now... Maybe
I'll find some inspiration over the weekend, but this kinda looks subtle
and evil :-<

--rafal

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