Date: Fri, 15 Nov 2002 09:09:32 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: ia64@FreeBSD.ORG Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Message-ID: <200211150909.32267.dfr@nlsystems.com> In-Reply-To: <20021114143809.A31710@kayak.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141951.41202.dfr@nlsystems.com> <20021114143809.A31710@kayak.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 14 November 2002 10:38 pm, Marcel Moolenaar wrote: > [moved to ia64@] > > On Thu, Nov 14, 2002 at 07:51:41PM +0000, Doug Rabson wrote: > > > > > 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. > > > > > > But you need a setjmp to save that context, right? How would you > > > otherwise return to the thread? > > > > I've managed to reload my memory from magtape :-). To use > > setjmp/longjmp for thread switching, you would need to call flushrs > > from setjmp. That would simplify longjmp at the cost of severely > > pessimising setjmp. > > This is exactly what we now have and what I'm willing to sacrificy at > this time. It's easy enough to optimize setjmp/longjmp once we have > the *context stuff. This is totally wrong. Typical programs use setjmp for marking locations=20 for error recovery and they call setjmp many more times than longjmp.=20 Forcing the register stack to be flushed on setjmp is broken. The old=20 code worked well for this normal case. I completely disagree that its a=20 good idea to seriously pessimise the performance for most users just to=20 add support for a feature that setjmp was never designed for. > > Note that I'm still not convinced that not doing a flushrs in setjmp > will work when a signal handler on the alternate stack jumps to the > saved context on the regular stack. You cannot compare the saved > ar.bsp or ar.bspstore with the current ar.bspstore without taking > into account that they may not be on the same register stack. The signal trampoline performs the flushrs when it switches stacks. This=20 means that the register backing store will contain correct values for=20 both execution paths in longjmp. It doesn't actually matter whether=20 longjmp flushes in this case (i.e. both paths end up with the same=20 correct result). The only real problem with this case is finding the=20 right value for ar.rnat. That register should go into the jmp_buf and=20 the flushrs should be removed. The code in longjmp would then look=20 something like this: =09mov=09r17=3Dar.bspstore =09;; =09cmp.ltu=09p6,p7=3Dr17,r16=09=09// r16=3Dsaved ar.bsp (p6)=09flushrs=09=09=09=09// flush setjmp's dirty regs (p7)=09loadrs=09=09=09=09// setjmp's regs are clean This way would work correctly (and would perform well) for all normal=20 users of setjmp/longjmp. For libc_r with the code written this way, you can probably still do=20 thread switching without swapcontext(2) by adding an explicit flushrs=20 before the call to setjmp(3). It would be less effort to write the=20 support for userland or kernel swapcontext though. --=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 freebsd-ia64" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211150909.32267.dfr>