Date: Mon, 18 Nov 2002 10:20:22 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Espen Skoglund <esk@ira.uka.de> Cc: ia64@freebsd.org Subject: Re: libc_r: syscalls, epc and unwinding [was: Re: setjmp/longjmp and libc_r...] Message-ID: <20021118182022.GB612@dhcp01.pn.xcllnt.net> In-Reply-To: <15832.53014.422459.568935@i30nb20.ira.uka.de> References: <200211140640.gAE6eNq9016231@repoman.freebsd.org> <200211161101.38075.dfr@nlsystems.com> <20021116172102.GA618@dhcp01.pn.xcllnt.net> <200211171017.30008.dfr@nlsystems.com> <20021117185344.GA603@athlon.pn.xcllnt.net> <15832.53014.422459.568935@i30nb20.ira.uka.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 18, 2002 at 12:29:26PM +0100, Espen Skoglund wrote:
>
> Why don't you have a separate entry point for each system call rather
> than having each call go to the generic GETAWAY_PAGE entry point?
We have a jumptable for syscalls and mostly common handling around it.
It wouldn't give us anything other than code duplication.
> This could allow you to do special optimizations. Some system calls,
> e.g., gettimeofday(), might even be run without even doing an epc.
You can still do that. You can filter based on the syscall number by
simple comparisons if the number of special cases is not too large.
Note also that any syscall you handle completely in userland is one
that cannot trigger signal delivery.
> Having separate entry points should also make it a whole lot easier
> for the branch prediction unit to do the right thing. On the other
> hand, you would have to predefine the entry points in the syscall ABI,
> and memory/cache footprint would probably increase a bit.
This would basicly make the jumptable visible to userland. Not a bad
idea per se, but there's a lot of code being run as a side-effect that
you then have to deal with differently. The end result may not be
more efficient.
> It would also be nice to have the getaway page mapped into the kernel
> region. This would allow the TLB entries for the getaway page to be
> shared among all address spaces.
There are some obvious improvements we can do WRT to the mapping. My
main objective first was a functional stub. I'm on a slight tangent
now WRT saving/restoring registers but that should give us the basics
for the actual syscall code and the {get|set|swap}context syscalls.
The bottom line is that this opens a lot of doors and it's probably
best to keep most of them closed until we got what we wanted.
--
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?20021118182022.GB612>