Benjamin Herrenschmidt wrote: > err = syscall(SYS_fallocate, fd, mode, offset, len); > > With "offset" being a 64-bit argument. > > This will break because the first argument to syscall now shifts > everything by one register, which breaks the register pair alignment > (and I suppose archs with stack based calling convention can have > similar alignment issues even if x86 doesn't). > > Ulrich, Steven, shouldn't we have glibc's syscall() take a long long as > it's first argument to correct that ? Either that or making it some kind > of macro wrapper around a __syscall(int dummy, int sysno, ...) ? > > As it is, any 32-bit app using syscall() on any of the syscalls that > takes 64-bit arguments will be broken, unless the app itself breaks up > the argument, but the the order of the hi and lo part is different > between BE and LE architectures ;-) > > So is there a more "correct" solution than another here ? Should powerpc > glibc be fixed at least so that syscall() keeps the alignment ? There are several problems with syscall(), not just this - because a number of system calls in section 2 of the manual don't map directly to kernel syscalls with the same function prototype. Even fork() has become something complicated in Glibc that doesn't use the fork syscall :-( So anything using syscall() has to be careful on Linux already. Changing the 64-bit alignment won't fix the other differences. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
