Details of MIPS(Octeon) system call semantics

Details of MIPS(Octeon) system call semantics

[adnan iqbal]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

hi everybody,

I am able to find system call list (o32 and n64) in
/usr/include/asm/unistd.h over octeon/debian board. I am looking for details
about these system calls so that for each system call i know exactly

1. What parmeters should be set in which registers before syscall
2. Which registers contain output of those system calls.


Thanks in advance for your help.
Regards
Adnan

[-- Attachment #2: Type: text/html, Size: 425 bytes --]

Re: Details of MIPS(Octeon) system call semantics

[Ralf Baechle]

On Wed, Jun 02, 2010 at 03:17:38PM +0500, adnan iqbal wrote:

> I am able to find system call list (o32 and n64) in
> /usr/include/asm/unistd.h over octeon/debian board. I am looking for details
> about these system calls so that for each system call i know exactly
> 
> 1. What parmeters should be set in which registers before syscall
> 2. Which registers contain output of those system calls.

The basic concept for all ABIs is that syscalls are working almost like
subroutine calls, so:

 o arguments are passed in $a0 - $a3 for o32
 o arguments are passed in $a0 - $a7 for N32 and N64
 o argument that don't fit into the argument registers are passed on the
   stack.
 o for details such as alignment of 64-bit arguments the usual ABI
   conventions apply
 o the result is return in $v0

In addition to normal subroutine calls:

 o $a3 on syscall return will indicate success or error.  0 means success,
   non-zero means an error happened in which case $v0 will contain an
   errno.h error code.
 o Many syscalls deviate from this convention.  For example the sigreturn
   family of syscalls doesn't return a result or error status.
 o pipe() will return the 2nd filedescriptor of the result in $v1.
 o vfork is even more weird.
 o The ABI differences mean there are many subtle difference between the
   syscall handlers.

  Ralf

Re: Details of MIPS(Octeon) system call semantics

[Maciej W. Rozycki]

On Wed, 2 Jun 2010, Ralf Baechle wrote:

> In addition to normal subroutine calls:
> 
>  o $a3 on syscall return will indicate success or error.  0 means success,
>    non-zero means an error happened in which case $v0 will contain an
>    errno.h error code.
>  o Many syscalls deviate from this convention.  For example the sigreturn
>    family of syscalls doesn't return a result or error status.
>  o pipe() will return the 2nd filedescriptor of the result in $v1.
>  o vfork is even more weird.
>  o The ABI differences mean there are many subtle difference between the
>    syscall handlers.

 All of the above plus $v0 holds the syscall number upon entry -- which 
you may effectively consider the "zeroth argument" to the call (the code 
field of the SYSCALL instruction is not used by Linux).

 Also it is mandated by the syscall restart mechanism used by signal 
delivery code that it must be the instruction physically immediately 
preceding the SYSCALL operation that places the syscall number in $v0.  
In most cases a LI operation is used, but this is not a requirement (such 
as utilised by the syscall(3) library wrapper) as long as no temporary 
registers are used to obtain the value, because in the case of a restart 
these will have been clobbered by the syscall being restarted (so e.g. lw 
$v0, 0x100($fp) is fine, but move $v0, $a3 is not).

  Maciej