Date: Thu, 14 Nov 2002 19:47:51 +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: <200211141947.51412.dfr@nlsystems.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>
index | next in thread | previous in thread | raw e-mail
On Thursday 14 November 2002 6:13 pm, 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) Ok, now I'm at home and I have time to read the code again. The reason you need a flushrs in longjmp is that you want to avoid using flushrs in setjmp (since setjmp is called many times more often than longjmp). This means that the stacked register state of the setjmp context can be partly contained in dirty registers. In setjmp, we record the value of ar.bsp, which is the address just after the last valid dirty register in setjmp's state. The region between ar.bspstore and ar.bsp represents backing store for those dirty registers. In longjmp, we examine ar.bspstore to see if it has passed that mark. If so, all setjmp's dirty registers are safely in backing store and all we need to do is invalidate the current register set (loadrs) and set ar.bspstore to the value that ar.bsp had at setjmp. If ar.bspstore has not passed out of the 'danger zone', we are forced to flushrs. We try not to flushrs for every call to longjmp but this is an optimisation. The code in _setjmp.S:1.8 is broken for the case when you are calling longjmp and ar.bspstore is within the region of memory backing setjmp's dirty registers. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211141947.51412.dfr>