This is the mail archive of the 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 Thu, 17 Aug 2017, Adhemerval Zanella wrote:

> My point is I think we should aim for compiler optimization safeness
> (to avoid code breakage over compiler defined default flags) and taking
> as base current approach to *avoid* VLA on GLIBC I do not think it is
> good approach to use it as a bridge to force GCC to generate the expected
> code.

 You certainly have a point here overall, although I don't think a VLA 
whose size is always 0 really hurts.  And we've used the approach with 
`alloca' since forever with no adverse effects until we added a place 
where the caller invokes the syscall wrapper in a loop.  So I wouldn't 
necessarily call it an issue.  Mind that this is target-specific code, so 
we can rely on a target-specific execution model rather than limiting 
ourselves to what generic ISO C guarantees.

 Aurelien's figures indicating a clear size reduction certainly count as a 
pro though.

> I still thinking trying to optimize for 5/6/7 syscall argument is over
> engineering in this *specific* case.  As I put in my last message,
> 5/6/7 argument syscalls are used for 
> pread, pwrite, lseek, llseek, ppoll, posix_fadvice, posix_fallocate, 
> sync_file_range, fallocate, preadv, pwritev, preadv2, pwritev2, select,
> pselect, mmap, readahead, epoll_pwait, splice, recvfrom, sendto, recvmmsg,
> msgsnd, msgrcv, msgget, msgctl, semop, semget, semctl, semtimedop, shmat,
> shmdt, shmget, and shmctl. 
> Which are the one generated from C implementation (some are still auto
> generated).  The majority of them are blocking syscalls, so both context
> switch plus the required work for syscall completion itself will taking
> proportionally all the required time.  So trying to squeeze some cycles
> don't really pay off comparing to code maintainability (just all this
> discussion of which C construct would be safe enough to generate the 
> correct stack spill plus the current issue should indicate we should
> aim for correctness first).

 TBH, I find it questionable whether it's really the approach I proposed 
that requires more engineering (and long-term maintenance) effort rather 
than using a separate handwritten assembly-language call stub.  Especially 
if a non-standard calling convention is used.

 If everyone but me thinks there's a clear advantage in using such a 
handcoded stub though, then as I previously noted please adjust the 
affected MIPS16 stubs to avoid the extra indirection, i.e. you can call 
`__libc_do_syscall' directly from MIPS16 code as you'd do from regular 
MIPS or microMIPS code, as the lone reason for the existence of the MIPS16 
stubs is the inexistence of a MIPS16 SYSCALL instruction.

 Once you're done with that I can push your proposed change through MIPS16 
regression testing if that helped.  I can see if I can run microMIPS 
testing as well, although I'd have to double-check for an available board 
as I don't use one regularly.


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