Date: Sat, 16 Nov 2002 09:21:02 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Doug Rabson <dfr@nlsystems.com> Cc: ia64@FreeBSD.ORG Subject: Re: libc_r: syscalls, epc and unwinding [was: Re: setjmp/longjmp and libc_r...] Message-ID: <20021116172102.GA618@dhcp01.pn.xcllnt.net> In-Reply-To: <200211161101.38075.dfr@nlsystems.com> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211151955.19145.dfr@nlsystems.com> <20021115130540.A34636@kayak.xcllnt.net> <200211161101.38075.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 16, 2002 at 11:01:38AM +0000, Doug Rabson wrote: > > > This also allows the possibility of saving/restoring the high > > > floating point state in user-mode instead of kernel mode which > > > might be a good thing in some situations. > > > > I have to think about this angle. I've been thinking about the high > > FPs in the context of SMP. The goal being to avoid saving the high FP > > in cpu_switch altogether and deal with processes moving to a > > different CPU in a lazy way. The same principle as avoiding the > > flushrs in setjmp... > > 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. > > > > 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: 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? 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. 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... -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021116172102.GA618>