Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On 05/30/2014 01:34 PM, Andy Lutomirski wrote: >> >> GET_LE() then? > > Sounds good. > > Are you planning on writing the patch? > > I think my v2 is good -- the only diff I could find in my image.c > files and Stephen's was in the alt_xyz output, and I think I fixed > that in v2. > Build testing one now. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On Fri, May 30, 2014 at 1:21 PM, H. Peter Anvin wrote: > On 05/30/2014 01:09 PM, Andy Lutomirski wrote: >>> >>> I came up with the following, it seems like a reasonable simplification: >>> #define _LE(x, bits, ifnot) \ __builtin_choose_expr( \ (sizeof(x) == bits/8), \ (__typeof__(x))le##bits##toh(x), ifnot) >> >> This will do awful things if x is a floating-point type, and, for >> integers, the cast is probably unnecessary. But it should be okay. >> > > I mostly wanted to preserve the signedness. Yes, if we care about > floating-point it gets trickier. > > At some point hopefully there will be a native C feature to handle this > crap. > extern void bad_le(uint64_t); >> >> If this ever goes in a common header, then we should do the >> __attribute__((error)) thing. I wonder if it would ever make sense to >> have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. >> #define _LAST_LE(x) \ __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) #define LE(x) \ _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x >>> >>> What do you think? >> >> My only real real objection is that _LE sounds like converting *to* >> little-endian to me. Admittedly, that's the same thing on any >> remotely sane architecture, but still. > > GET_LE() then? Sounds good. Are you planning on writing the patch? I think my v2 is good -- the only diff I could find in my image.c files and Stephen's was in the alt_xyz output, and I think I fixed that in v2. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On 05/30/2014 01:09 PM, Andy Lutomirski wrote: >> >> I came up with the following, it seems like a reasonable simplification: >> >>> #define _LE(x, bits, ifnot) \ >>> __builtin_choose_expr( \ >>> (sizeof(x) == bits/8), \ >>> (__typeof__(x))le##bits##toh(x), ifnot) > > This will do awful things if x is a floating-point type, and, for > integers, the cast is probably unnecessary. But it should be okay. > I mostly wanted to preserve the signedness. Yes, if we care about floating-point it gets trickier. At some point hopefully there will be a native C feature to handle this crap. >>> extern void bad_le(uint64_t); > > If this ever goes in a common header, then we should do the > __attribute__((error)) thing. I wonder if it would ever make sense to > have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. > >>> #define _LAST_LE(x) \ >>> __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) >>> >>> #define LE(x) \ >>> _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x >> >> What do you think? > > My only real real objection is that _LE sounds like converting *to* > little-endian to me. Admittedly, that's the same thing on any > remotely sane architecture, but still. GET_LE() then? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On Fri, May 30, 2014 at 1:02 PM, H. Peter Anvin wrote: > On 05/30/2014 08:48 AM, Andy Lutomirski wrote: >> This adds a macro GET(x) to convert x from big-endian to >> little-endian. Hopefully I put it everywhere it needs to go and got >> all the cases needed for everyone's linux/elf.h. >> >> Signed-off-by: Andy Lutomirski >> --- >> arch/x86/vdso/vdso2c.c | 15 >> arch/x86/vdso/vdso2c.h | 63 >> -- >> 2 files changed, 50 insertions(+), 28 deletions(-) > > A couple of observations: > > 1. We shouldn't use double-underscore in host C code. > > 2. It would be nice if we can take these sort of things (host-build >helper macros) and move them to some common file in the Linux kernel >eventually, so it would be a good thing to make the naming a little >less general. > > 3. Even though it isn't necessary, making it work on 8-bit values so >one doesn't have to worry about the type would seem like a good >thing. > > I came up with the following, it seems like a reasonable simplification: > >> #define _LE(x, bits, ifnot) \ >> __builtin_choose_expr( \ >> (sizeof(x) == bits/8), \ >> (__typeof__(x))le##bits##toh(x), ifnot) This will do awful things if x is a floating-point type, and, for integers, the cast is probably unnecessary. But it should be okay. >> >> extern void bad_le(uint64_t); If this ever goes in a common header, then we should do the __attribute__((error)) thing. I wonder if it would ever make sense to have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. >> #define _LAST_LE(x) \ >> __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) >> >> #define LE(x) \ >> _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x > > What do you think? My only real real objection is that _LE sounds like converting *to* little-endian to me. Admittedly, that's the same thing on any remotely sane architecture, but still. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On 05/30/2014 08:48 AM, Andy Lutomirski wrote: > This adds a macro GET(x) to convert x from big-endian to > little-endian. Hopefully I put it everywhere it needs to go and got > all the cases needed for everyone's linux/elf.h. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/vdso/vdso2c.c | 15 > arch/x86/vdso/vdso2c.h | 63 > -- > 2 files changed, 50 insertions(+), 28 deletions(-) A couple of observations: 1. We shouldn't use double-underscore in host C code. 2. It would be nice if we can take these sort of things (host-build helper macros) and move them to some common file in the Linux kernel eventually, so it would be a good thing to make the naming a little less general. 3. Even though it isn't necessary, making it work on 8-bit values so one doesn't have to worry about the type would seem like a good thing. I came up with the following, it seems like a reasonable simplification: > #define _LE(x, bits, ifnot) \ > __builtin_choose_expr( \ > (sizeof(x) == bits/8), \ > (__typeof__(x))le##bits##toh(x), ifnot) > > extern void bad_le(uint64_t); > #define _LAST_LE(x) \ > __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) > > #define LE(x) \ > _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x What do you think? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On 05/30/2014 08:48 AM, Andy Lutomirski wrote: This adds a macro GET(x) to convert x from big-endian to little-endian. Hopefully I put it everywhere it needs to go and got all the cases needed for everyone's linux/elf.h. Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/vdso/vdso2c.c | 15 arch/x86/vdso/vdso2c.h | 63 -- 2 files changed, 50 insertions(+), 28 deletions(-) A couple of observations: 1. We shouldn't use double-underscore in host C code. 2. It would be nice if we can take these sort of things (host-build helper macros) and move them to some common file in the Linux kernel eventually, so it would be a good thing to make the naming a little less general. 3. Even though it isn't necessary, making it work on 8-bit values so one doesn't have to worry about the type would seem like a good thing. I came up with the following, it seems like a reasonable simplification: #define _LE(x, bits, ifnot) \ __builtin_choose_expr( \ (sizeof(x) == bits/8), \ (__typeof__(x))le##bits##toh(x), ifnot) extern void bad_le(uint64_t); #define _LAST_LE(x) \ __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) #define LE(x) \ _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x What do you think? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On Fri, May 30, 2014 at 1:02 PM, H. Peter Anvin h...@zytor.com wrote: On 05/30/2014 08:48 AM, Andy Lutomirski wrote: This adds a macro GET(x) to convert x from big-endian to little-endian. Hopefully I put it everywhere it needs to go and got all the cases needed for everyone's linux/elf.h. Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/vdso/vdso2c.c | 15 arch/x86/vdso/vdso2c.h | 63 -- 2 files changed, 50 insertions(+), 28 deletions(-) A couple of observations: 1. We shouldn't use double-underscore in host C code. 2. It would be nice if we can take these sort of things (host-build helper macros) and move them to some common file in the Linux kernel eventually, so it would be a good thing to make the naming a little less general. 3. Even though it isn't necessary, making it work on 8-bit values so one doesn't have to worry about the type would seem like a good thing. I came up with the following, it seems like a reasonable simplification: #define _LE(x, bits, ifnot) \ __builtin_choose_expr( \ (sizeof(x) == bits/8), \ (__typeof__(x))le##bits##toh(x), ifnot) This will do awful things if x is a floating-point type, and, for integers, the cast is probably unnecessary. But it should be okay. extern void bad_le(uint64_t); If this ever goes in a common header, then we should do the __attribute__((error)) thing. I wonder if it would ever make sense to have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. #define _LAST_LE(x) \ __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) #define LE(x) \ _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x What do you think? My only real real objection is that _LE sounds like converting *to* little-endian to me. Admittedly, that's the same thing on any remotely sane architecture, but still. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On 05/30/2014 01:09 PM, Andy Lutomirski wrote: I came up with the following, it seems like a reasonable simplification: #define _LE(x, bits, ifnot) \ __builtin_choose_expr( \ (sizeof(x) == bits/8), \ (__typeof__(x))le##bits##toh(x), ifnot) This will do awful things if x is a floating-point type, and, for integers, the cast is probably unnecessary. But it should be okay. I mostly wanted to preserve the signedness. Yes, if we care about floating-point it gets trickier. At some point hopefully there will be a native C feature to handle this crap. extern void bad_le(uint64_t); If this ever goes in a common header, then we should do the __attribute__((error)) thing. I wonder if it would ever make sense to have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. #define _LAST_LE(x) \ __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) #define LE(x) \ _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x What do you think? My only real real objection is that _LE sounds like converting *to* little-endian to me. Admittedly, that's the same thing on any remotely sane architecture, but still. GET_LE() then? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On Fri, May 30, 2014 at 1:21 PM, H. Peter Anvin h...@zytor.com wrote: On 05/30/2014 01:09 PM, Andy Lutomirski wrote: I came up with the following, it seems like a reasonable simplification: #define _LE(x, bits, ifnot) \ __builtin_choose_expr( \ (sizeof(x) == bits/8), \ (__typeof__(x))le##bits##toh(x), ifnot) This will do awful things if x is a floating-point type, and, for integers, the cast is probably unnecessary. But it should be okay. I mostly wanted to preserve the signedness. Yes, if we care about floating-point it gets trickier. At some point hopefully there will be a native C feature to handle this crap. extern void bad_le(uint64_t); If this ever goes in a common header, then we should do the __attribute__((error)) thing. I wonder if it would ever make sense to have __LINUX_HOSTPROG__ and make some of the basic headers work. Hmm. #define _LAST_LE(x) \ __builtin_choose_expr(sizeof(x) == 1, (x), bad_le(x)) #define LE(x) \ _LE(x, 64, _LE(x, 32, _LE(x, 16, _LAST_LE(x What do you think? My only real real objection is that _LE sounds like converting *to* little-endian to me. Admittedly, that's the same thing on any remotely sane architecture, but still. GET_LE() then? Sounds good. Are you planning on writing the patch? I think my v2 is good -- the only diff I could find in my image.c files and Stephen's was in the alt_xyz output, and I think I fixed that in v2. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86,vdso: Fix cross-compilation from big-endian architectures
On 05/30/2014 01:34 PM, Andy Lutomirski wrote: GET_LE() then? Sounds good. Are you planning on writing the patch? I think my v2 is good -- the only diff I could find in my image.c files and Stephen's was in the alt_xyz output, and I think I fixed that in v2. Build testing one now. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
