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? All
existing syscall-making code I've seen depends at least on r4-r7 not
being clobbered when a signal interrupts a syscall 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). These are
requirements beyond the normal function call convention (which does
not require the callee preserve the values of r4-r7).
As for my problem, I can use r7 as the temp ("move $2,$7 ; syscall")
for syscalls with 3 or fewer args, but for the 4-arg syscall, $7 is
occupied by an argument, and I'd need to spill the syscall number to
the stack to be able to restore it if $25 is not available...
Rich
