This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] mips/o32: fix internal_syscall5/6/7


On 2017-08-16 11:13, Adhemerval Zanella wrote:
> 
> 
> On 16/08/2017 10:44, Joseph Myers wrote:
> > On Wed, 16 Aug 2017, Maciej W. Rozycki wrote:
> > 
> >> On Tue, 15 Aug 2017, Joseph Myers wrote:
> >>
> >>> In which case having a volatile integer variable with value 4, declaring a 
> >>> VLA whose size is that variable, and storing a pointer to that VLA in a 
> >>> variable, would be an alternative to alloca to force a frame pointer, but 
> >>> with deallocation happening when the scope ends rather than the function 
> >>> ending (and the syscall macro has its own scope, so using it inside a loop 
> >>> wouldn't be a problem).
> >>
> >>  I suspect using volatile variables will cause unnecessary memory traffic.  
> >> Passing the size specifier through an empty `asm' might give better code; 
> >> also I think we can use 0 as the size requested, not to decrease the stack 
> >> pointer unnecessarily, e.g.:
> > 
> > Sure, as long as (a) the compiler can't know the size is actually constant 
> > and (b) it can't know the VLA isn't actually used, as if it can tell 
> > either of those things it can optimize away the variable stack allocation.
> > 
> >>  Also I wonder if there's actually a dependable way to have GCC itself 
> >> allocate the argument space we require.  For example if we set `s' to 1 
> >> above instead for `internal_syscall6', then would `0($sp)' and `4($sp)' be 
> >> valid to place arguments #5 and #6 at respectively without the subsequent 
> >> $sp adjustment we currently have in the syscall `asm' or would it be UB?
> > 
> > You can't tell whether the compiler might have allocated other variables 
> > on the stack after the dynamic adjustment - that is, whether any 
> > particular offset from sp is in fact unused or not.
> > 
> 
> What about the below? I can use some help to see if I am handling all the
> required ABI requirements for the __libc_do_syscall, but on an qemu emulated
> system I see no regression on basic tests (including some cancellation one
> from glibc to see the syscall is correctly unwinded) and tst-rwlock15 also
> does not fail anymore.

Thanks for this patch, I'll give it a try. I have been working on
something similar, however I only routed the syscalls with 5, 6 or 7
arguments to the __libc_do_syscall. That way there is no performance
penalty for them as they are the most used ones.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]