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: Jamie Lokier on 17 Mar 2010 05:20 Benjamin Herrenschmidt wrote: > Hence, apps that use the first form today because it works on x86 would > end up working at least on powerpc where they would have been otherwise > broken unless they used some arch specific #ifdef to do the second form. I think what Ulrich is getting at is your change will break existing code which already does: #ifdef __powerpc__ syscall(SYS_foo, 0, my_64bit_arg); #else syscall(SYS_foo, my_64bit_arg); #endif I don't know of any such code, but it might be out there. -- Jamie -- 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: Ulrich Drepper on 17 Mar 2010 05:20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2010 01:56 AM, Benjamin Herrenschmidt wrote: >> - You keep the existing syscall() exported by glibc for binary >> compatibility > >> - You add a new __syscall() (or whatever you want to name it) that adds >> a dummy argument at the beginning, and whose implementation shifts >> everything by 2 instead of 1 argument before calling into the kernel > >> - You define in unistd.h or whatever is relevant, a macro that does: > >> #define syscall(__sysno, __args..) __syscall(0, _sysno, __args) > >> I believe that should cover it, at least for powerpc, possibly for other >> archs too though as I said, I may have missed something there. How can this possibly be the case? This will screw people who currently work around the ppc limitations of the existing syscall. Just leave it alone. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkugnV0ACgkQ2ijCOnn/RHRL4gCeIY0SLDCgLqtVvuMw+pvCzkwE 3MIAoJQRK5Mc+WtC/Wz9tPFPy4X+EALe =lexw -----END PGP SIGNATURE----- -- 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 06:20 On Wed, 2010-03-17 at 02:14 -0700, Ulrich Drepper wrote: > >> I believe that should cover it, at least for powerpc, possibly for > other > >> archs too though as I said, I may have missed something there. > > How can this possibly be the case? This will screw people who > currently > work around the ppc limitations of the existing syscall. No it won't. As I said, it will work for both cases. The problem is a register pair alignment problem. If the alignment is corrected with the trick I proposed, 64-bit values will end up in the right pair, but manually worked-around cases where the value is already broken up will -also- end up in the right pair. The problem with syscall() as it is is that it skews the arguments by 1 register, which causes the compiler to skip a register when generating the call for a 64-bit value. By doing the trick I propose, that skew will be gone, both 32 and 64 bit arguments will end up where expected. 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: Benjamin Herrenschmidt on 17 Mar 2010 06:30 On Wed, 2010-03-17 at 09:18 +0000, Jamie Lokier wrote: > Benjamin Herrenschmidt wrote: > > Hence, apps that use the first form today because it works on x86 would > > end up working at least on powerpc where they would have been otherwise > > broken unless they used some arch specific #ifdef to do the second form. > > I think what Ulrich is getting at is your change will break existing > code which already does: > > #ifdef __powerpc__ > syscall(SYS_foo, 0, my_64bit_arg); > #else > syscall(SYS_foo, my_64bit_arg); > #endif > > I don't know of any such code, but it might be out there. No, the above "workaround" doesn't work. With the existing syscall() definition, there is no difference between your two examples. In the first case, you force a proper 64-bit aligment, but you are already off by one register pair from the kernel expectation. In the second case, gcc will imply one, which means that both your examples above will result in my_64bit_arg in the -same- place, which is off by a register pair from what the kernel expect. IE. In the first case gcc will put SYS_foo in r3, 0 in r4, and my_64bit_arg in r5 and r6. In the second case, gcc will put SYS_foo in r3, won't care about r4, and will put the 64-bit arg in r5 and r6. Then, glibc syscall() will shift r3 to r0, r3 to r4 etc... causing my_64bit_arg to land in r4 and r5. But the kernel expects it in r3 and r4. The workaround that apps should use today is: #if defined(__powerpc__) && WORDSIZE == 32 syscall(SYS_foo, (u32)(my_64bit_arg >> 32), (u32)my_64bit_arg); #else syscall(SYS_foo, my_64bit_arg); #endif And with my proposed change, both of the above will work. IE. gcc will put the argument always in r5,r6 and the syscall() implementation will always shift r5 to r3 and t6 to r4. 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 14:40
On 03/17/2010 01:56 AM, Benjamin Herrenschmidt wrote: > > Ok, so I -may- be missing something, but I believe this won't break > anything: > > - You keep the existing syscall() exported by glibc for binary > compatibility > > - You add a new __syscall() (or whatever you want to name it) that adds > a dummy argument at the beginning, and whose implementation shifts > everything by 2 instead of 1 argument before calling into the kernel > > - You define in unistd.h or whatever is relevant, a macro that does: > > #define syscall(__sysno, __args..) __syscall(0, _sysno, __args) > Again, this is *exactly* symbol versioning done by hand... we have proper symbol versioning, let's use it. -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/ |