[Linux-ia64] Re: [RFC] proposed change for syscall stub

[Linux-ia64] Re: [RFC] proposed change for syscall stub

[David Mosberger]

Jim Hull noticed that I posted the wrong code for the syscall stub:
the one I sent out fits in 5 bundles, not 4 as advertised.  The
4-bundle code looks like this:

really_new_syscall_stub:
	adds r2 = SYSINFO_OFF, r13;;
	ld8 r2 = [r2]
	mov r9 = ar.pfs;;
	mov r15 = SYSCALL_NR
	mov b7 = r2
	br.call.sptk.many b6 = b7;;
	cmp.eq p6,p0 = -1, r10
	mov ar.pfs = r9
(p6)	br.cond.spnt.few syscall_error
	br.ret.sptk.many rp;;

The only difference here is that we dirty both b6 and b7, which allows
us to remove one stop bit and hence save one bundle.  On McKinley,
dirtying more scratch branch registers may impact branch target
address prediction accuracy, but the effect is small enough that I
decided to go for better code-density instead.

	--david

[Linux-ia64] Re: [RFC] proposed change for syscall stub

[Peter Chubb]

>>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:


really_new_syscall_stub: 
	adds r2 = SYSINFO_OFF, r13;; 
	ld8 r2 = [r2] 
	mov r9 = ar.pfs;; 
	mov r15 = SYSCALL_NR 
	mov b7 = r2
	br.call.sptk.many b6 = b7;; 
	cmp.eq p6,p0 = -1, r10 
	mov ar.pfs = r9 
(p6)	br.cond.spnt.few syscall_error 
	br.ret.sptk.many rp;;

David> Here, SYSINFO_OFF is the offset in the user-level thread-control-block
David> at which the system call entry point is stored.  glibc initializes
David> this value to point to the following piece of code:


The ABI only allows 16 bytes for the TCB pointed to by R13; 
the first 8 bytes are a pointer to the dynamic thread vector, the
second 8 bytes a pointer to the per-thread thread-library-private data
(for linuxthreads, it points to a _pthread_descr)

So is the idea to extend the TCB (in contravention of the current
ABI), or should this code have an extra level of indirection, to get at the
sysinfo field from the library-specific structure?

Or am I missing something obvious?


--
Dr Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

Re: [Linux-ia64] Re: [RFC] proposed change for syscall stub

[David Mosberger]

>>>>> "Peter" = Peter Chubb <peter@chubb.wattle.id.au> writes:

 >>>>> "David" = David Mosberger <davidm@napali.hpl.hp.com> writes:

 David> really_new_syscall_stub:
 David> 	adds r2 = SYSINFO_OFF, r13;;
 David> 	ld8 r2 = [r2]
 David> 	mov r9 = ar.pfs;;
 David> 	mov r15 = SYSCALL_NR
 David> 	mov b7 = r2
 David> 	br.call.sptk.many b6 = b7;;
 David> 	cmp.eq p6,p0 = -1, r10
 David> 	mov ar.pfs = r9
 David> (p6)	br.cond.spnt.few syscall_error
 David> 	br.ret.sptk.many rp;;

 David> Here, SYSINFO_OFF is the offset in the user-level
 David> thread-control-block at which the system call entry point is
 David> stored.  glibc initializes this value to point to the
 David> following piece of code:

 Peter> The ABI only allows 16 bytes for the TCB pointed to by R13;
 Peter> the first 8 bytes are a pointer to the dynamic thread vector,
 Peter> the second 8 bytes a pointer to the per-thread
 Peter> thread-library-private data (for linuxthreads, it points to a
 Peter> _pthread_descr)

Correct.

 Peter> So is the idea to extend the TCB (in contravention of the
 Peter> current ABI), or should this code have an extra level of
 Peter> indirection, to get at the sysinfo field from the
 Peter> library-specific structure?

The ABI only regulates positive offsets.  The current glibc stores the
actual (p-)thread-control block _below_ the thread-pointer.  I have a
glibc prototype which stores the sysinfo pointer at offset -8.  Seems
to work fine so far (see
http://sources.redhat.com/ml/libc-hacker/2003-01/msg00118.html).

BTW: I forgot that "r9" is used by some syscalls (e.g., pipe()) to
return a second value, so we can't use it in the syscall stub to
preserve ar.pfs.  I changed the stub to use "r11" instead (which
should be safe) and, while doing that, also added the necessary unwind
directives.  So the stub now stands at:

REALLY_new_syscall_stub:
	.prologue
 	adds r2 = SYSINFO_OFF, r13;;
 	ld8 r2 = [r2]
	.save ar.pfs, r11
 	mov r11 = ar.pfs;;
	.body
 	mov r15 = SYSCALL_NR
 	mov b7 = r2
 	br.call.sptk.many b6 = b7;;
 	cmp.eq p6,p0 = -1, r10
	.restore sp
 	mov ar.pfs = r11
(p6)	br.cond.spnt.few syscall_error
 	br.ret.sptk.many rp;;

I should have a kernel patch out soon (perhaps tonight) which will add
fsys-mode (light-weight system call) support to the kernel.  (Only for
getpid at the moment; I mainly care about getting the infrastructure
in place, we can add lightweight syscall handlers over time.)

	--david

Re: [Linux-ia64] Re: [RFC] proposed change for syscall stub

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Chubb wrote:
>>>>>>"David" = David Mosberger <davidm@napali.hpl.hp.com> writes:
> 
> 
> 
> really_new_syscall_stub: 
> 	adds r2 = SYSINFO_OFF, r13;; 
> 	ld8 r2 = [r2] 
> 	mov r9 = ar.pfs;; 
> 	mov r15 = SYSCALL_NR 
> 	mov b7 = r2
> 	br.call.sptk.many b6 = b7;; 
> 	cmp.eq p6,p0 = -1, r10 
> 	mov ar.pfs = r9 
> (p6)	br.cond.spnt.few syscall_error 
> 	br.ret.sptk.many rp;;
> 
> David> Here, SYSINFO_OFF is the offset in the user-level thread-control-block
> David> at which the system call entry point is stored.  glibc initializes
> David> this value to point to the following piece of code:
> 
> 
> The ABI only allows 16 bytes for the TCB pointed to by R13; 
> the first 8 bytes are a pointer to the dynamic thread vector, the
> second 8 bytes a pointer to the per-thread thread-library-private data
> (for linuxthreads, it points to a _pthread_descr)

I haven't yet decided how I'll handle this for IA-64 but I think the
thread descriptor should be placed before what the IA-64 ABI
unfortunately calls TCB.  I.e., SYSINFO_OFF will be a negative value.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+JLXi2ijCOnn/RHQRAgHLAJ9l2WqOeUqjK4uqVvR7Cp0SO58a6QCghwB/
mR6zJ3mrvjlB7GycnU3cqNUhG8
-----END PGP SIGNATURE-----