From owner-freebsd-ia64 Fri Nov 15 9:43:38 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 42F5537B401 for ; Fri, 15 Nov 2002 09:43:37 -0800 (PST) Received: from kayak.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB00A43E3B for ; Fri, 15 Nov 2002 09:43:35 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAFHhU0N034073; Fri, 15 Nov 2002 09:43:30 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id gAFHhTRM004359; Fri, 15 Nov 2002 09:43:29 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id gAFHhTc3004358; Fri, 15 Nov 2002 09:43:29 -0800 (PST) (envelope-from marcel) Date: Fri, 15 Nov 2002 09:43:29 -0800 From: Marcel Moolenaar To: Doug Rabson Cc: ia64@FreeBSD.ORG Subject: Re: setjmp/longjmp and libc_r [was: Re: cvs commit: src/lib/libc/ia64/gen _setjmp.S] Message-ID: <20021115174328.GA4288@dhcp01.pn.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211141951.41202.dfr@nlsystems.com> <20021114143809.A31710@kayak.xcllnt.net> <200211150909.32267.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211150909.32267.dfr@nlsystems.com> User-Agent: Mutt/1.5.1i 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 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. > > 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... > 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... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message