64-syscall args on 32-bit vs syscall()
in [Kernel]
|
Prev: [PATCH -rc] memcg: disable move charge in no mmu case
Next: [PATCH] x86,perf: Enable not tagged retired instruction counting
From: Benjamin Herrenschmidt on 17 Mar 2010 16:40 On Wed, 2010-03-17 at 11:30 -0700, H. Peter Anvin wrote: > Again, this is *exactly* symbol versioning done by hand... we have > proper symbol versioning, let's use it. Yeah, whatever, I don't mind what technique you use for the versionning, ultimately, if the approach works, we can look at those details :-) We -do- need the macro to strip the dummy argument though, unless we use a slightly different technique which is to make the __sysno argument itself 64-bit, which works as well I believe. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 17 Mar 2010 17:00 On 03/17/2010 01:35 PM, Benjamin Herrenschmidt wrote: > On Wed, 2010-03-17 at 11:30 -0700, H. Peter Anvin wrote: >> Again, this is *exactly* symbol versioning done by hand... we have >> proper symbol versioning, let's use it. > > Yeah, whatever, I don't mind what technique you use for the versionning, > ultimately, if the approach works, we can look at those details :-) We > -do- need the macro to strip the dummy argument though, unless we use > a slightly different technique which is to make the __sysno argument > itself 64-bit, which works as well I believe. > It seems cleaner to do it that way (with a 64-bit sysno arg.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 17 Mar 2010 19:10 On Wed, 2010-03-17 at 13:53 -0700, H. Peter Anvin wrote: > > Yeah, whatever, I don't mind what technique you use for the > versionning, > > ultimately, if the approach works, we can look at those details :-) > We > > -do- need the macro to strip the dummy argument though, unless we > use > > a slightly different technique which is to make the __sysno argument > > itself 64-bit, which works as well I believe. > > > > It seems cleaner to do it that way (with a 64-bit sysno arg.) Right. Now if we can get Ulrich to actually put 2 and 2 together and admit that it actually works without breaking anything existing (at least for my arch but I wouldn't be surprised if that was the case for others), I would be even happier :-) Steve, any chance you can cook up a glibc patch to test with ? Maybe making it powerpc specific for now ? Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steven Munroe on 18 Mar 2010 12:00 On Thu, 2010-03-18 at 09:58 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2010-03-17 at 13:53 -0700, H. Peter Anvin wrote: > > > Yeah, whatever, I don't mind what technique you use for the > > versionning, > > > ultimately, if the approach works, we can look at those details :-) > > We > > > -do- need the macro to strip the dummy argument though, unless we > > use > > > a slightly different technique which is to make the __sysno argument > > > itself 64-bit, which works as well I believe. > > > > > > > It seems cleaner to do it that way (with a 64-bit sysno arg.) > > Right. Now if we can get Ulrich to actually put 2 and 2 together and > admit that it actually works without breaking anything existing (at > least for my arch but I wouldn't be surprised if that was the case for > others), I would be even happier :-) > > Steve, any chance you can cook up a glibc patch to test with ? Maybe > making it powerpc specific for now ? > Do what declare __sysno as long long? The current prototype is in unistd.h: #ifdef __USE_MISC /* Invoke `system call' number SYSNO, passing it the remaining arguments. This is completely system-dependent, and not often useful. In Unix, `syscall' sets `errno' for all errors and most calls return -1 for errors; in many systems you cannot pass arguments or get return values for all system calls (`pipe', `fork', and `getppid' typically among them). In Mach, all system calls take normal arguments and always return an error code (zero for success). */ extern long int syscall (long int __sysno, ...) __THROW; #endif /* Use misc. */ Changing this would be an ABI change and would have to be versioned. It would effect any one using syscall not just SYS_fallocate. the question is do programmers in practice include unistd.h when they use syscall. If the changed prototype is not in scope then the 1st parm (__sysno) defaults to int and is passed in on r3 which gets moved to r0. If the changed syscall prototype is in scope then then _sysno would be passed in r3/r4 (r3 would be 0 would be passed to r0 and the actual system number would be in r4 and passed to the kernel in r3) which behavior do you want? which (incorrect behavior compiled into existing codes do you want to support? Do you want syscall.S for PPC32 to change to match the changed prototype? It will have to be be versioned and the new prototype will only be available in future releases of GLIBC. Existing applications will bind to the old ABI and get the old behavior. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Steven Munroe on 18 Mar 2010 13:00
On Thu, 2010-03-18 at 17:21 +0100, Andreas Schwab wrote: > Steven Munroe <munroesj(a)linux.vnet.ibm.com> writes: > > > extern long int syscall (long int __sysno, ...) __THROW; > > > > #endif /* Use misc. */ > > > > Changing this would be an ABI change and would have to be versioned. It > > would effect any one using syscall not just SYS_fallocate. > > > > the question is do programmers in practice include unistd.h when they > > use syscall. > > > > If the changed prototype is not in scope then the 1st parm (__sysno) > > defaults to int and is passed in on r3 which gets moved to r0. > > int is incompatible with long, so you already get undefined behaviour > anyway. > Sorry in and long are compatible in 32-bit but not long long. int and long are not compatible in 64-bit It is hard the keep all the nodes and arguments straight. But the concern about changing the prototype and are people actually using the prototype are still valid. > Andreas. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |