setjmp() shares a single jmp_buf across all threads

Andrew Haley aph@cambridge.redhat.com
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.



More information about the Java mailing list