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 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 leaving setjmp/longjmp the way it is as long as it goes back to the efficient way as soon as we have a working set of getcontext, 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 was available in the trapframe. Another possible (3) would be a hybrid user-syscall version which flushes the register stack and accesses the floating point state in user mode. You could even recognise the *context syscalls in exception.s and write them as special cases of do_syscall. Come to think of it, you will almost certainly have to do the flushrs in user mode. The different alignments of user and kernel stacks would 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 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 but I can't quite see how they would make it easier to switch the inaccessable parts of the register state. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +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>