From owner-freebsd-ia64 Fri Nov 15 11:55:27 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 1040937B401 for ; Fri, 15 Nov 2002 11:55:25 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [62.49.251.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F26A43E42 for ; Fri, 15 Nov 2002 11:55:23 -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 gAFJtJDP002686; Fri, 15 Nov 2002 19:55:19 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 19:55:19 +0000 User-Agent: KMail/1.4.3 Cc: ia64@FreeBSD.ORG References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211150909.32267.dfr@nlsystems.com> <20021115174328.GA4288@dhcp01.pn.xcllnt.net> In-Reply-To: <20021115174328.GA4288@dhcp01.pn.xcllnt.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200211151955.19145.dfr@nlsystems.com> X-Spam-Status: No, hits=-7.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, 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 Friday 15 November 2002 5:43 pm, Marcel Moolenaar wrote: > On Fri, Nov 15, 2002 at 09:09:32AM +0000, Doug Rabson wrote: > > > > 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. > > No, it's a step in different direction than you would have chosen. > Pick your words with care. See also below. I didn't choose this direction, Intel recommends it. From the IA-64=20 System Architecture manual, section 15.5.1.1: =09This permits execution of a setjmp() without having to manipulate any =09register stack or RSE state. All register stack and RSE manipulation i= s =09postponed to the much less frequent longjmp(). > > > > 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. > > Ah, I see. You avoid having the dirty registers on the kernel stack > by doing an exception restore to the original stack, do a flushrs and > then switch to the alternate stack. I wondered about this > hoop-jumping... This also allows the possibility of saving/restoring the high floating=20 point state in user-mode instead of kernel mode which might be a good=20 thing in some situations. > > > 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. > > I've been looking at that. If by implementing the *context functions > we speed-up the adoption of *context by libc_r, then I'm willing to > spend time on it. What I don't want is spending time on *context and > in the end not have libc_r, due to it not being changed to use it. > > Thus: I want people to sign-up for a libc_r that uses *context before > 5.0-RELEASE, but preferrably tomorrow. A well-intended timeline would > be very nice... I want to see a libc_r which uses *context too. Its trivial to write=20 thread switching this way and they are designed for it (i.e. no more MD=20 grovelling around in the jmp_buf to setup the stack etc). I've been=20 using makecontext/switchcontext in my own code and it works very well.=20 Changing libc_r to switch this way should be easy if Dan hasn't already=20 done it. --=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