proposed change for syscall stub

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

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 [email protected]
You are lost in a maze of BitKeeper repositories, all almost the same.

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

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

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-----