This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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