Date: 14 Nov 2002 18:28:55 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S Message-ID: <1037298535.19149.8.camel@builder02.qubesoft.com> In-Reply-To: <20021114181340.GA603@dhcp01.pn.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141009.45000.dfr@nlsystems.com> <20021114181340.GA603@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2002-11-14 at 18:13, Marcel Moolenaar wrote: > 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) You would need a flushrs if you really wanted to use longjmp for thread switching, otherwise you would lose the stacked registers of the thread you were switching away from. Perhaps the best approach really is to put ar.rnat in the jmp_buf here instead of grovelling around on the register stack for it. I still need think about this more carefully and re-read the code. One case which its is important not to break is longjmp to a context which is still part of the dirty register state. > > > 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. This is ok because you don't have to be able to switch back to the altstack context. > > 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. I don't think thread switching is (should be) part of the functional specification of setjmp/longjmp. We are going to change libc_r to use swapcontext anyway. Supporting thread switching severely pessimises the common case due to the potentially large number of dirty stacked registers. 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?1037298535.19149.8.camel>