>Number:         11987
>Category:       port-i386
>Synopsis:       lib/libc/arch/i386/sys/{__,}syscall.S do not meet up with other code
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 17 18:30:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Jun-ichiro itojun Hagino
>Release:        1.5Q
>Organization:
	itojun.org
>Environment:
System: NetBSD starfruit.itojun.org 1.5Q NetBSD 1.5Q (STARFRUIT) #328: Wed Jan 17 20:01:52 JST 2001 itojun@starfruit.itojun.org:/usr/home/itojun/NetBSD/src/sys/arch/i386/compile/STARFRUIT i386
Architecture: i386
Machine: i386
>Description:
	it looks that lib/libc/arch/i386/sys/{__,}syscall.S behavior do
	not meet with other architectures.

	suppose a someone used the following code:
		syscall(SYS_foo, bar, baz)
	for non-i386 architectures, we pass the following syscall # SYS_syscall
	and pass the syscall # originally issued as arguments to "SYS_syscall".
	so,
		syscall # is SYS_syscall
		1st argument is SYS_foo
		2nd argument is bar
		3rd argument is baz
	for __syscall, the story goes the same.  the call:
		__syscall((u_quad_t)SYS_foo, bar, baz)
	the arguments:
		syscall # is SYS___syscall
		1st argument is 1st half of SYS_foo
		2nd argument is 2nd half of SYS_foo
		3rd argument is bar
		4th argument is baz

	lib/libc/arch/i386/sys/{__,}syscall.S plays with stack, and effectively
	implement different thing.  for syscall, it will do the following:
		syscall # is SYS_foo
		1st argument is bar
		2nd argument is baz
	for __syscall, it implements the same behavior, dropping upper 32bit
	of syscall # (SYS_foo).

	it does not generate a real issue, as long as syscall # fits into
	32bits.  I believe __syscall() was designed to allow 64bit syscall #.
	if someone ever try to use 64bit syscall #, he/she will lose.
>How-To-Repeat:
	code inspection
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: