On 09/10/2012 10:22 AM, Rich Felker wrote:
On Mon, Sep 10, 2012 at 07:08:30PM +0200, Ralf Baechle wrote:
On Sun, Sep 09, 2012 at 03:30:08PM -0400, Rich Felker wrote:
The kernel syscall entry/exit code seems to always save and restore
r25. Is this stable/documented behavior I can rely on? If there's a
reason it _needs_ to be preserved, knowing that would help convince me
it's safe to assume it will always be done. The intended usage is to
be able to make syscalls (where the syscall # is not a constant that
could be loaded with lwi) without a stack frame, as in "move $2,$25 ;
syscall".
The basic design idea is that syscalls use a calling convention similar
to subroutine calls. $25 is $t9, so a temp register which is callee saved.
So if the kernel is saving $t9 and you've been relying on that, consider
yourself lucky - there's not guarantee for that.
Is there any documentation of what the kernel does guarantee?
Not really. The glibc souces can be used as the canonical
implementation as we cannot break it. glibc assumes $25 is clobbered.
All
existing syscall-making code I've seen depends at least on r4-r7 not
being clobbered when a signal interrupts a syscall
This is an internal kernel implementation detail. Relying on it in
userspace is probably not a good idea.
and sets it up for
restart (since the arguments still need to be there when it's
restarted), and seems to also depend on r4-r6 not being clobbered when
the syscall successfully returns (since they're not listed in the
clobber list, e.g. in uClibc's inline syscall asm).
Some versions of uClibc's inline syscall asm are buggy. So they cannot
be used as an indication of what is supported.
These are
requirements beyond the normal function call convention (which does
not require the callee preserve the values of r4-r7).
I would assume these are clobbered (from glibc sources
ports/sysdeps/unix/sysv/linux/mips/mips64/n64/sysdep.h):
"$1", "$3", "$10", "$11", "$12", "$13", "$14", "$15", "$24", "$25",
"hi", "lo"
David Daney
