Date: Sun, 17 Nov 2002 10:17:29 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: ia64@FreeBSD.ORG Subject: Re: libc_r: syscalls, epc and unwinding [was: Re: setjmp/longjmp and libc_r...] Message-ID: <200211171017.30008.dfr@nlsystems.com> In-Reply-To: <20021116172102.GA618@dhcp01.pn.xcllnt.net> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211161101.38075.dfr@nlsystems.com> <20021116172102.GA618@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 16 November 2002 5:21 pm, Marcel Moolenaar wrote: > On Sat, Nov 16, 2002 at 11:01:38AM +0000, Doug Rabson wrote: > > I thought that we already did this - we defer switching the FP > > state until the thread takes a VEC_DISABLED_FP trap. > > We always save and drop the state in the SMP case. That is, if the > CPU holds the high FP state of the thread being switched. Of course, I forgot about that part. The only alternative to that I can=20 see is cpu-locking a thread which owns the fp state . > > > > > > 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 thread switching this way and they are designed for it > > > > (i.e. no more MD grovelling around in the jmp_buf to setup the > > > > stack etc). I've been using makecontext/switchcontext in my own > > > > code and it works very well. Changing libc_r to switch this way > > > > should be easy if Dan hasn't already done it. > > > > > > Ok. I guess this is the best I can get. I'll work on it this > > > weekend. I'll restore the previous behaviour of setjmp/longjmp > > > while I'm at it. > > > > Thanks. Sorry if I've come over a bit dogmatic on the subject but I > > do think that using longjmp to switch stacks is dubious on any > > architecture and specially for ia64. At least switchcontext is > > designed for the job :-). > > This whole situation has put me in a place where I didn't want to be: > Dan has removed the userland *context functions and created syscalls. > This we wanted of course, but we're not ready yet to have the > syscalls. Ergo: progress on libc_r has been endangered :-( > I have a couple of approaches: Sorry about that. After thinking about this, I have no real objection to=20 leaving setjmp/longjmp the way it is as long as it goes back to the=20 efficient way as soon as we have a working set of getcontext,=20 setcontext, swapcontext. > > 1. Bite the bullet and implement EPC for syscalls. This is an ABI > breaker and best be done before release, but has high impact. As > a side-effect, I might be able to save the preserved registers as > a special case to avoid having to depend on unwinding, which we > don't have reliably yet for this purpose. Is almost a single- > commit change, but very very attractive... > 2. Finish the unwinding job I started and use it for the *context > syscalls. High impact, but can be spread over many commits; > 3. more? I had forgotten that not all of the state for getcontext and setcontext=20 was available in the trapframe. Another possible (3) would be a hybrid=20 user-syscall version which flushes the register stack and accesses the=20 floating point state in user mode. You could even recognise the=20 *context syscalls in exception.s and write them as special cases of=20 do_syscall. Come to think of it, you will almost certainly have to do the flushrs in=20 user mode. The different alignments of user and kernel stacks would=20 make doing it manually quite messy. > > On the subject of unwinding: > > I talked to David Mosberger yesterday. He told me of a case where > unwinding is being used to implement longjmp. It would be very > interesting to find out in how many steps one can unwind to the > context of setjmp and how much performance gain it gives. It probably depends on how many levels need unwinding. The setjmp would=20 be very fast though. > > Also, David is willing to change the license of his libunwind library > if he thinks that's beneficial (for him of course). I also talked to > Cary Coutant and he also has something we might use, but chances are > slimmer (HP internal source with an intention to open source it). > In short: I'm looking into ways to avoid that we have to flesh out > our own unwinder in the kernel, provided we can find code that is > suitable for our use. In this light, doing EPC now helps because > otherwise I would end up fleshing out our unwinder anyway. > > I'll give this some thought over coffee... Why would EPC syscalls make this easier? Obviously they would be faster=20 but I can't quite see how they would make it easier to switch the=20 inaccessable parts of the register state. --=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?200211171017.30008.dfr>