Date: Thu, 14 Nov 2002 10:09:44 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S Message-ID: <200211141009.45000.dfr@nlsystems.com> In-Reply-To: <200211140640.gAE6eNq9016231@repoman.freebsd.org> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 14 November 2002 6:40 am, Marcel Moolenaar wrote: > marcel 2002/11/13 22:40:23 PST > > Modified files: > lib/libc/ia64/gen _setjmp.S > Log: > o Fix _longjmp() to return 1 when the return value is given as 0. > o Remove the unwanted smartness in _longjmp() where it compares > the current ar.bspstore with the saved ar.bspstore and restores > ar.rnat based on it. This either avoids saving ar.rnat in the > jmp_buf or is the consequence of not saving ar.rnat. All this > complexity breaks libc_r where we use longjmp() to switch to > different threads and the current ar.bspstore has no relation > to the saved ar.bspstore. Thus: we save ar.rnat in setjmp() > and simply restore ar.bspstore and ar.rnat in longjmp(). This is wrong, I think. The purpose of the comparing bspstore values is=20 to avoid a forced flushrs in the normal case of unwinding a single=20 stack. This is the intel-recommended approach for implementing longjmp.=20 We need to use switchcontext() for libc_r which knows that it is=20 switching stacks and can flush the register stack appropriately. I=20 don't think it would ever be a good idea to use longjmp for thread=20 switches on ia64. --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211141009.45000.dfr>