Date: Fri, 15 Nov 2002 19:55:19 +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: <200211151955.19145.dfr@nlsystems.com> In-Reply-To: <20021115174328.GA4288@dhcp01.pn.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211150909.32267.dfr@nlsystems.com> <20021115174328.GA4288@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211151955.19145.dfr>