Re: [PATCH][BZ #15054] MIPS: Fix syscall wrappers for syscall restart support

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Wed, 23 Jan 2013, Mike Frysinger wrote:

> >  We have an issue with the INTERNAL_SYSCALL_NCS wrapper in that it does
> > not respect the kernel's syscall restart convention.
> > 
> >  That convention requires the instruction immediately preceding SYSCALL to
> > initialize $v0 with the syscall number.  Then if a restart triggers, $v0
> > will have been clobbered by the syscall interrupted, and needs to be
> > reinititalized.  The kernel will decrement the PC by 4 before switching
> > back to the user mode so that $v0 has been reloaded before SYSCALL is
> > executed again.  This implies the place $v0 is loaded from must be
> > preserved across a syscall, e.g. an immediate, static register, stack
> > slot, etc.
> 
> naïvely, but why can't the mips kernel paths take care of the reload itself ?  
> other arches have scratch space in their pt_regs for doing just this (a bunch 
> of arches use the orig_<reg> convention).

 I agree it would be the most reasonable approach if designing from 
scratch; unfortunately what we have is how the ABI has been set back in 
1994.  You won't be able to patch up all the kernel binaries out there, 
sigh...

 OTOH, the cost of hardcoding the extra instruction to precede SYSCALL is 
not something I would bend backwards to get rid of, especially given how 
rarely we make syscalls whose number is not a compilation-time constant.  
As a matter of curiosity I've run `objdump' across the set of shared 
libraries we build and found just two such places, in libpthread: 
sighandler_setxid and __nptl_setxid, out of 243 SYSCALL instances total.  
I don't suppose the number is going to rise dramatically anytime soon 
either.

  Maciej