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>
index | next in thread | previous in thread | raw e-mail
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 for error recovery and they call setjmp many more times than longjmp. Forcing the register stack to be flushed on setjmp is broken. The old code worked well for this normal case. I completely disagree that its a good idea to seriously pessimise the performance for most users just to 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 means that the register backing store will contain correct values for both execution paths in longjmp. It doesn't actually matter whether longjmp flushes in this case (i.e. both paths end up with the same correct result). The only real problem with this case is finding the right value for ar.rnat. That register should go into the jmp_buf and the flushrs should be removed. The code in longjmp would then look something like this: mov r17=ar.bspstore ;; cmp.ltu p6,p7=r17,r16 // r16=saved ar.bsp (p6) flushrs // flush setjmp's dirty regs (p7) loadrs // setjmp's regs are clean This way would work correctly (and would perform well) for all normal users of setjmp/longjmp. For libc_r with the code written this way, you can probably still do thread switching without swapcontext(2) by adding an explicit flushrs before the call to setjmp(3). It would be less effort to write the support for userland or kernel swapcontext though. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the messagehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211150909.32267.dfr>