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>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20 you need a flushrs in longjmp is that you want to avoid using flushrs=20 in setjmp (since setjmp is called many times more often than longjmp).=20 This means that the stacked register state of the setjmp context can be=20 partly contained in dirty registers. In setjmp, we record the value of ar.bsp, which is the address just=20 after the last valid dirty register in setjmp's state. The region=20 between ar.bspstore and ar.bsp represents backing store for those dirty=20 registers. In longjmp, we examine ar.bspstore to see if it has passed=20 that mark. If so, all setjmp's dirty registers are safely in backing=20 store and all we need to do is invalidate the current register set=20 (loadrs) and set ar.bspstore to the value that ar.bsp had at setjmp. If=20 ar.bspstore has not passed out of the 'danger zone', we are forced to=20 flushrs. We try not to flushrs for every call to longjmp but this is an=20 optimisation. The code in _setjmp.S:1.8 is broken for the case when you are calling=20 longjmp and ar.bspstore is within the region of memory backing setjmp's=20 dirty registers. --=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?200211141947.51412.dfr>