[Gc] Setjmp_t meaning

Boehm, Hans hans.boehm at hp.com
Wed Oct 20 14:32:24 PDT 2004

I haven't looked at this in detail recently, but my impression is
that this test is not very reliable.  The generic code may work
when setjmp_t reports that it doesn't.  This can probably
happen if x gets stack allocated, which is probably not unlikely,
especially on register-poor architectures.

The idea is to check whether all registers are saved in the
setjmp buffer, or whether longjmp relies on registers that
were save on the stack being restored during stack unwinding.
(On some architectures, longjmp unwinds the stack until it gets
back to the setjmp frame.  In other cases, the contents for the
jmpbuf are simply copied back.  The unwind-based implementations
will probably not work here, since the collector may never see
callee-save registers.

With gcc, the collector in fact tries to use __builtin_unwind_init
instead of setjmp in the generic case, which may be more robust here.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Peter Colson
> Sent: Tuesday, October 19, 2004 11:55 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Setjmp_t meaning
> Concerning the setjmp_t test program, I'm trying to 
> understand how this 
> program determines that GC_generic_push_regs can/cannot work 
> on a given 
> platform.
> My understanding is that setjmp() saves registers into the 
> jmpbuf. When 
> longjmp() occurs if the var x contains the value 2 set prior to the 
> longjmp, rather than the 1 that it contained prior to setjmp, 
> we can't 
> use the generic routine.
> Why is that? What has just been indicated here.
> I'm trying to understand this for porting libgc to a platform that 
> indicates the generic version won't work.
> Regards,
> Peter Colson.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list