Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!cs.utexas.edu!uunet!ssbell!mcmi!unocss!zycor!bill
From: bill@zycor.UUCP (bill)
Newsgroups: comp.unix.wizards
Subject: Re: Indirect system call
Message-ID: <67@zycor.UUCP>
Date: 10 Nov 89 16:44:17 GMT
References: <28945@shemp.CS.UCLA.EDU>
Reply-To: bill@zycor.UUCP (bill)
Organization: zycor, Inc. - Omaha, NE
Lines: 30

In article <28945@shemp.CS.UCLA.EDU> dieter@lynn.cs.ucla.edu (Dieter Rothmeier) writes:
>While browsing through section 2 of the Unix manual,
>I came upon the concept of an indirect system call,
>as in syscall(2). Now that puzzled me. What might be
>the use for such a facility?

You have stumbled on an interesting quirk in some implementations of UNIX.
It would seem that some processors don't expect the data for a
system call to be on the user stack, but instead immediately following
the system-call opcode in the user address space. In other words, 
something like:
	syscall	5
	word	v1
	word	v2
instead of the more common way that system calls work in a CPU:
	push	v2
	push	v1
	syscall	5

(So on the OS side, it uses the saved PC to access the operands
instead of the user stack pointer).

The problem is that if the system call instruction is in the TEXT
segment you can't write variable quantities after the syscall
opcode, since the text is r/o. Thus, you put the actual opcode
and its operands out in the data segment, and the indirect system
call points at the real one. 

The only time I have seen this was years ago on an Onyx running 7.

Bill Mahoney
bill@zycor.UUCP
The holiday season: time to wonder if the Salvation Army has tanks...