From owner-freebsd-ia64 Fri Nov 15 1: 9:40 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 042A637B401 for ; Fri, 15 Nov 2002 01:09:38 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7436243E42 for ; Fri, 15 Nov 2002 01:09:36 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring [10.0.0.2]) by herring.nlsystems.com (8.12.6/8.12.6) with ESMTP id gAF99WDP091140; Fri, 15 Nov 2002 09:09:33 GMT (envelope-from dfr@nlsystems.com) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Marcel Moolenaar Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Date: Fri, 15 Nov 2002 09:09:32 +0000 User-Agent: KMail/1.4.3 Cc: ia64@FreeBSD.ORG References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141951.41202.dfr@nlsystems.com> <20021114143809.A31710@kayak.xcllnt.net> In-Reply-To: <20021114143809.A31710@kayak.xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211150909.32267.dfr@nlsystems.com> X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_KMAIL version=2.41 Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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