Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.
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. Maciej
[8]ページ先頭