Date: Thu, 14 Nov 2002 10:13:40 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S Message-ID: <20021114181340.GA603@dhcp01.pn.xcllnt.net> In-Reply-To: <200211141009.45000.dfr@nlsystems.com> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141009.45000.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 14, 2002 at 10:09:44AM +0000, Doug Rabson wrote: > 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 > to avoid a forced flushrs in the normal case of unwinding a single > stack. This is the intel-recommended approach for implementing longjmp. Why do you need a flushrs in longjmp() anyway? All you really need to achieve is that ar.bsp equals ar.bspstore before you set ar.bspstore, right? (note that the loadrs is missing a cover or an alloc) > We need to use switchcontext() for libc_r which knows that it is > switching stacks and can flush the register stack appropriately. I > don't think it would ever be a good idea to use longjmp for thread > switches on ia64. Don't forget that signal handlers on alternate stacks can use longjmp to switch to a context on the normal stack. If setjmp/longjmp has to handle those cases as well, I don't see why they cannot now handle thread switching for the time being. It's good to eventually optimize setjmp/longjmp for the common case, but at this time it's all we have and I think we'd better focus on being functionally complete. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20021114181340.GA603>