setjmp() shares a single jmp_buf across all threads

Mon Jan 14 14:36:00 GMT 2002

Adam Megacz writes:
 > 
 > Andrew Haley <aph@cambridge.redhat.com> writes:
 > > Looks like gcc doesn't know about your threads package.
 > 
 > Hrm, I configured with --enable-threads=win32...
 > 
 > > Look in gcc/unwind-sjlj.c. See:
 > > void _Unwind_SjLj_Register (struct SjLj_Function_Context *fc)
 > 
 > This is completely bizarre; I put an infinite loop at the top of this
 > function, yet when I recompile/link/run programs that throw
 > exceptions, they don't hang.
Okay. Look at the gcj generated assembler source of a function with a
catch clause and see what function is being called.
 > After grepping through the source, I found that the symbol
 > _Unwind_SjLj_Register doesn't appear anywhere outside of
 > unwind-sjlj.c... where is this function called from?
Sure it does. It's a libfunc.
optabs.c:4961: unwind_sjlj_register_libfunc = init_one_libfunc ("_Unwind_SjLj_Register");
 > > You need to provide some local way of getting/setting thread-specific
 > > data. I reckon if you fix this, everything will "just work". :-)
 > 
 > Yeah, gthr-win32.c defines an implementation (TlsSet/TlsGet) which
 > ought to work, I just don't think it's getting called.
Yes; it needs to be.
 > Another question: what is the difference between the "builtin setjmp"
 > and the non-builtin setjmp? Does "builtin" mean that the compiler just
 > dumps out code to do setjmp's work instead of emitting a call to a
 > library function?
Exactly.
Andrew.