setjmp() shares a single jmp_buf across all threads
Mon Jan 14 14:36:00 GMT 2002
Adam Megacz writes:
> Andrew Haley <firstname.lastname@example.org> 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?
More information about the Java