Hi,
Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
https://sites.google.com/site/x32abi/
The major remaining issues are glibc/gcc testsuite failures,
kernel core dump and signal handler unwind.
--
H.J.
On Sat, Mar 5, 2011 at 11:08 AM, H.J. Lu <[email protected]> wrote:
> Hi,
>
> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>
> https://sites.google.com/site/x32abi/
>
> The major remaining issues are glibc/gcc testsuite failures,
> kernel core dump and signal handler unwind.
>
I checked in a kernel patch:
http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.37.y.git;a=commitdiff;h=7fd04de9dca8871772d97928c338d4a2eb315c2b
and a GCC patch:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00267.html
to fix signal handler unwind.
--
H.J.
On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>
> https://sites.google.com/site/x32abi/
>
> The major remaining issues are glibc/gcc testsuite failures,
> kernel core dump and signal handler unwind.
are you getting a unique host tuple for this ? or are you extending x86_64-
linux-gnu ? so the only way of knowing which ABI is to check for the output
of the compiler+compiler flags ?
-mike
On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger <[email protected]> wrote:
> On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>>
>> https://sites.google.com/site/x32abi/
>>
>> The major remaining issues are glibc/gcc testsuite failures,
>> kernel core dump and signal handler unwind.
>
> are you getting a unique host tuple for this ? ?or are you extending x86_64-
> linux-gnu ? ?so the only way of knowing which ABI is to check for the output
> of the compiler+compiler flags ?
x32 requires x32 enabled x86-64 kernel.
--
H.J.
Hi,
Almost all x32 bugs in kernel, glibc and binutils are fixed:
https://sites.google.com/site/x32abi/
There are no unexpected failures in glibc testsuite. I am
working on remaining GCC bugs.
--
H.J.
On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> >> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
> >>
> >> https://sites.google.com/site/x32abi/
> >>
> >> The major remaining issues are glibc/gcc testsuite failures,
> >> kernel core dump and signal handler unwind.
> >
> > are you getting a unique host tuple for this ? or are you extending
> > x86_64- linux-gnu ? so the only way of knowing which ABI is to check
> > for the output of the compiler+compiler flags ?
>
> x32 requires x32 enabled x86-64 kernel.
ok, but that doesnt answer my question. what are you passing to --target ?
-mike
On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger <[email protected]> wrote:
> On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
>> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> >> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>> >>
>> >> https://sites.google.com/site/x32abi/
>> >>
>> >> The major remaining issues are glibc/gcc testsuite failures,
>> >> kernel core dump and signal handler unwind.
>> >
>> > are you getting a unique host tuple for this ? ?or are you extending
>> > x86_64- linux-gnu ? ?so the only way of knowing which ABI is to check
>> > for the output of the compiler+compiler flags ?
>>
>> x32 requires x32 enabled x86-64 kernel.
>
> ok, but that doesnt answer my question. ?what are you passing to --target ?
See:
https://sites.google.com/site/x32abi/
You configure it as
CC="gcc -mx32" ...../configure x86_64- linux-gnu
--
H.J.
On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger <[email protected]> wrote:
> > On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
> >> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
> >> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> >> >> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
> >> >>
> >> >> https://sites.google.com/site/x32abi/
> >> >>
> >> >> The major remaining issues are glibc/gcc testsuite failures,
> >> >> kernel core dump and signal handler unwind.
> >> >
> >> > are you getting a unique host tuple for this ? or are you extending
> >> > x86_64- linux-gnu ? so the only way of knowing which ABI is to check
> >> > for the output of the compiler+compiler flags ?
> >>
> >> x32 requires x32 enabled x86-64 kernel.
> >
> > ok, but that doesnt answer my question. what are you passing to --target
> > ?
>
> See:
>
> https://sites.google.com/site/x32abi/
>
> You configure it as
>
> CC="gcc -mx32" ...../configure x86_64- linux-gnu
that isnt what the page says. it does say for glibc to do:
CC="x32-gcc -mx32 " CXX="x32-g++ -mx32 " CFLAGS="-O2 -g" ../configure
but it doesnt say what to do for binutils or gcc itself. obviously you cant
use the -mx32 flag when building the cross gcc for the first time since the
current native gcc wont support it.
the invocation given for glibc implies that the proposed tuple is x32-linux-
gnu, but the GNU config project doesnt support that tuple and i didnt see
mention of it in the binutils or gcc sources.
so we get back to my original e-mail:
are you getting a unique host tuple for this ? or are you extending
x86_64-linux-gnu ? so the only way of knowing which ABI is to check for
the output of the compiler+compiler flags ?
-mike
On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger <[email protected]> wrote:
> On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger <[email protected]> wrote:
>> > On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> >> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
>> >> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> >> >> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>> >> >>
>> >> >> https://sites.google.com/site/x32abi/
>> >> >>
>> >> >> The major remaining issues are glibc/gcc testsuite failures,
>> >> >> kernel core dump and signal handler unwind.
>> >> >
>> >> > are you getting a unique host tuple for this ? ?or are you extending
>> >> > x86_64- linux-gnu ? ?so the only way of knowing which ABI is to check
>> >> > for the output of the compiler+compiler flags ?
>> >>
>> >> x32 requires x32 enabled x86-64 kernel.
>> >
>> > ok, but that doesnt answer my question. ?what are you passing to --target
>> > ?
>>
>> See:
>>
>> https://sites.google.com/site/x32abi/
>>
>> You configure it as
>>
>> CC="gcc -mx32" ...../configure x86_64- linux-gnu
>
> that isnt what the page says. ?it does say for glibc to do:
> ? ? ? ?CC="x32-gcc -mx32 " CXX="x32-g++ -mx32 " CFLAGS="-O2 -g" ?../configure
>
> but it doesnt say what to do for binutils or gcc itself. ?obviously you cant
> use the -mx32 flag when building the cross gcc for the first time since the
> current native gcc wont support it.
>
> the invocation given for glibc implies that the proposed tuple is x32-linux-
> gnu, but the GNU config project doesnt support that tuple and i didnt see
> mention of it in the binutils or gcc sources.
>
> so we get back to my original e-mail:
> ? ? ? ?are you getting a unique host tuple for this ? ?or are you extending
> ? ? ? ?x86_64-linux-gnu ? ?so the only way of knowing which ABI is to check for
> ? ? ? ?the output of the compiler+compiler flags ?
As I said, the target is x86_64- linux-gnu and you just add -mx32 to CFLAGS.
The x86_64- linux-gnu binutils and GCC support x32.
--
H.J.
Mike Frysinger <[email protected]> writes:
> but it doesnt say what to do for binutils or gcc itself. obviously you cant
> use the -mx32 flag when building the cross gcc for the first time since the
> current native gcc wont support it.
Of course, for a compiler tool the only thing that matters is the
target.
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
> > so we get back to my original e-mail:
> > are you getting a unique host tuple for this ? or are you
> > extending x86_64-linux-gnu ? so the only way of knowing which ABI is to
> > check for the output of the compiler+compiler flags ?
>
> As I said, the target is x86_64- linux-gnu and you just add -mx32 to
> CFLAGS. The x86_64- linux-gnu binutils and GCC support x32.
ok, took long enough, but that answers most things. your usage of "x32-"
prefixed binaries in the documentation seems to imply a lot more than the fact
you just picked those locally to avoid system collisions. this isnt a wiki
page, otherwise i'd clean things up for you.
in looking at the gcc files, it doesnt seem like there's any defines setup to
declare x32 directly. instead, you'd have to do something like:
#ifdef __x86_64__
# if __SIZEOF_LONG__ == 8
/* x86_64 */
# else
/* x32 */
# endif
#endif
any plans on adding an __x32__ (or whatever) cpp symbol to keep people from
coming up with their own special/broken crap ? or are there some already that
i'm not seeing ?
-mike
On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <[email protected]> wrote:
> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
>> > so we get back to my original e-mail:
>> > ? ? ? ?are you getting a unique host tuple for this ? ?or are you
>> > extending x86_64-linux-gnu ? ?so the only way of knowing which ABI is to
>> > check for the output of the compiler+compiler flags ?
>>
>> As I said, the target is x86_64- linux-gnu and you just add -mx32 to
>> CFLAGS. The x86_64- linux-gnu binutils and GCC support ?x32.
>
> ok, took long enough, but that answers most things. ?your usage of "x32-"
> prefixed binaries in the documentation seems to imply a lot more than the fact
> you just picked those locally to avoid system collisions. ?this isnt a wiki
> page, otherwise i'd clean things up for you.
Any suggestion how to create a wiki page for x32?
> in looking at the gcc files, it doesnt seem like there's any defines setup to
> declare x32 directly. ?instead, you'd have to do something like:
> #ifdef __x86_64__
> # if __SIZEOF_LONG__ == 8
> /* x86_64 */
> # else
> /* x32 */
> # endif
> #endif
>
> any plans on adding an __x32__ (or whatever) cpp symbol to keep people from
> coming up with their own special/broken crap ? ?or are there some already that
> i'm not seeing ?
The idea is in most cases, you only need to check __x86_64__ since x32 and
x86-64 are very close. In some cases, x32 is very different from x86_64, like
assembly codes on long and pointer, you can check __x86_64__ and __LP64__.
In glibc, I used a different approach by using macros REG_RAX, .., MOV_LP,
ADD_LP, SUB_LP and CMP_LP in assembly codes.
I added a simple howto for x32 compiling to
https://sites.google.com/site/x32abi/
Thanks.
--
H.J.
On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <[email protected]> wrote:
> > ok, took long enough, but that answers most things. your usage of "x32-"
> > prefixed binaries in the documentation seems to imply a lot more than the
> > fact you just picked those locally to avoid system collisions. this
> > isnt a wiki page, otherwise i'd clean things up for you.
>
> Any suggestion how to create a wiki page for x32?
seems like the sites.google.com documentation says it includes wiki support.
http://sites.google.com/site/projectwikitemplate_en/
ive never used google sites before, so i dont know how to actually enable it
on the admin side of things.
> > in looking at the gcc files, it doesnt seem like there's any defines
> > setup to declare x32 directly. instead, you'd have to do something
> > like: #ifdef __x86_64__
> > # if __SIZEOF_LONG__ == 8
> > /* x86_64 */
> > # else
> > /* x32 */
> > # endif
> > #endif
> >
> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
> > from coming up with their own special/broken crap ? or are there some
> > already that i'm not seeing ?
>
> The idea is in most cases, you only need to check __x86_64__ since x32 and
> x86-64 are very close. In some cases, x32 is very different from x86_64,
> like assembly codes on long and pointer, you can check __x86_64__ and
> __LP64__. In glibc, I used a different approach by using macros REG_RAX,
> .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly codes.
arm/mips/ppc sets up explicit ABI defines to clearly differentiate between
things. while __LP64__ should work here, it seems like a poor substitute.
how about builtin_define("__X32__") ? or __ABI_X32__ ? doesnt seem like i386
has a standard in this regard to piggy off of.
-mike
in looking at how syscalls are implemented, i see that you've picked a base of
4096. so syscall numbers [0...4096) are for x86_64 and [4096...-1) are for
x32. this 4096 limit is a bit low isnt it ? seems like the best bet would be
to bisect the available space for each new ABI ...
ARM EABI picked 0x900000 for their base when adding a new ABI ...
-mike
On Wed, Mar 16, 2011 at 10:45 PM, Mike Frysinger <[email protected]> wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <[email protected]> wrote:
>> > ok, took long enough, but that answers most things. ?your usage of "x32-"
>> > prefixed binaries in the documentation seems to imply a lot more than the
>> > fact you just picked those locally to avoid system collisions. ?this
>> > isnt a wiki page, otherwise i'd clean things up for you.
>>
>> Any suggestion how to create a wiki page for x32?
>
> seems like the sites.google.com documentation says it includes wiki support.
> ? ? ? ?http://sites.google.com/site/projectwikitemplate_en/
>
> ive never used google sites before, so i dont know how to actually enable it
> on the admin side of things.
I will take a look.
>> > in looking at the gcc files, it doesnt seem like there's any defines
>> > setup to declare x32 directly. ?instead, you'd have to do something
>> > like: #ifdef __x86_64__
>> > # if __SIZEOF_LONG__ == 8
>> > /* x86_64 */
>> > # else
>> > /* x32 */
>> > # endif
>> > #endif
>> >
>> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
>> > from coming up with their own special/broken crap ? ?or are there some
>> > already that i'm not seeing ?
>>
>> The idea is in most cases, you only need to check __x86_64__ since x32 and
>> x86-64 are very close. ?In some cases, x32 is very different from x86_64,
>> like assembly codes on long and pointer, you can check __x86_64__ and
>> __LP64__. In glibc, I used a different approach by using macros REG_RAX,
>> .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly codes.
>
> arm/mips/ppc sets up explicit ABI defines to clearly differentiate between
> things. ?while __LP64__ should work here, it seems like a poor substitute.
> how about builtin_define("__X32__") ? ?or __ABI_X32__ ? ?doesnt seem like i386
> has a standard in this regard to piggy off of.
If you can show me some real examples how __x32__ will be used, I will
take a look.
Thanks.
--
H.J.
On 03/16/2011 10:21 PM, H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <[email protected]> wrote:
>> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
>>>> so we get back to my original e-mail:
>>>> are you getting a unique host tuple for this ? or are you
>>>> extending x86_64-linux-gnu ? so the only way of knowing which ABI is to
>>>> check for the output of the compiler+compiler flags ?
>>>
>>> As I said, the target is x86_64- linux-gnu and you just add -mx32 to
>>> CFLAGS. The x86_64- linux-gnu binutils and GCC support x32.
>>
>> ok, took long enough, but that answers most things. your usage of "x32-"
>> prefixed binaries in the documentation seems to imply a lot more than the fact
>> you just picked those locally to avoid system collisions. this isnt a wiki
>> page, otherwise i'd clean things up for you.
>
> Any suggestion how to create a wiki page for x32?
Hanging it off of gcc.gnu.org/wiki wouldn't be a bad idea, imo.
r~
On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <[email protected]> wrote:
> > in looking at the gcc files, it doesnt seem like there's any defines
> > setup to declare x32 directly. instead, you'd have to do something
> > like: #ifdef __x86_64__
> > # if __SIZEOF_LONG__ == 8
> > /* x86_64 */
> > # else
> > /* x32 */
> > # endif
> > #endif
> >
> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
> > from coming up with their own special/broken crap ? or are there some
> > already that i'm not seeing ?
>
> The idea is in most cases, you only need to check __x86_64__ since x32 and
> x86-64 are very close. In some cases, x32 is very different from x86_64,
> like assembly codes on long and pointer, you can check __x86_64__ and
> __LP64__. In glibc, I used a different approach by using macros REG_RAX,
> .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly codes.
while i agree with you in general that this is how people should be doing
things, in practice i often see people fishing around. education only goes so
far, so if there was an __x32__ define, i feel like people are more likely to
get it right than wrong.
i dont have any use cases off the top of my head, but i wouldnt be surprised
if the heavy inline assembly people (like the multimedia peeps e.g. libav)
approached it this way. rather than google for documentation, look at the cpp
output between -m64 and -mx32 and see what sticks out. "__x32__" would
certainly do that.
-mike
On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger <[email protected]> wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <[email protected]> wrote:
>> > in looking at the gcc files, it doesnt seem like there's any defines
>> > setup to declare x32 directly. ?instead, you'd have to do something
>> > like: #ifdef __x86_64__
>> > # if __SIZEOF_LONG__ == 8
>> > /* x86_64 */
>> > # else
>> > /* x32 */
>> > # endif
>> > #endif
>> >
>> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
>> > from coming up with their own special/broken crap ? ?or are there some
>> > already that i'm not seeing ?
>>
>> The idea is in most cases, you only need to check __x86_64__ since x32 and
>> x86-64 are very close. ?In some cases, x32 is very different from x86_64,
>> like assembly codes on long and pointer, you can check __x86_64__ and
>> __LP64__. In glibc, I used a different approach by using macros REG_RAX,
>> .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly codes.
>
> while i agree with you in general that this is how people should be doing
> things, in practice i often see people fishing around. ?education only goes so
> far, so if there was an __x32__ define, i feel like people are more likely to
> get it right than wrong.
>
> i dont have any use cases off the top of my head, but i wouldnt be surprised
> if the heavy inline assembly people (like the multimedia peeps e.g. libav)
> approached it this way. ?rather than google for documentation, look at the cpp
> output between -m64 and -mx32 and see what sticks out. ?"__x32__" would
> certainly do that.
My point is __x86_64__ version should work for both 64bit and x32. There should
no need for a separate x32 version.
--
H.J.
On Monday, March 21, 2011 01:35:35 H.J. Lu wrote:
> On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
> > On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> >> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> >> > in looking at the gcc files, it doesnt seem like there's any defines
> >> > setup to declare x32 directly. instead, you'd have to do something
> >> > like: #ifdef __x86_64__
> >> > # if __SIZEOF_LONG__ == 8
> >> > /* x86_64 */
> >> > # else
> >> > /* x32 */
> >> > # endif
> >> > #endif
> >> >
> >> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
> >> > from coming up with their own special/broken crap ? or are there some
> >> > already that i'm not seeing ?
> >>
> >> The idea is in most cases, you only need to check __x86_64__ since x32
> >> and x86-64 are very close. In some cases, x32 is very different from
> >> x86_64, like assembly codes on long and pointer, you can check
> >> __x86_64__ and __LP64__. In glibc, I used a different approach by using
> >> macros REG_RAX, .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly
> >> codes.
> >
> > while i agree with you in general that this is how people should be doing
> > things, in practice i often see people fishing around. education only
> > goes so far, so if there was an __x32__ define, i feel like people are
> > more likely to get it right than wrong.
> >
> > i dont have any use cases off the top of my head, but i wouldnt be
> > surprised if the heavy inline assembly people (like the multimedia peeps
> > e.g. libav) approached it this way. rather than google for
> > documentation, look at the cpp output between -m64 and -mx32 and see
> > what sticks out. "__x32__" would certainly do that.
>
> My point is __x86_64__ version should work for both 64bit and x32. There
> should no need for a separate x32 version.
yes, and my point is that people often reach for cpp defines rather than
figure out how to do it right.
i'm not saying that __x32__ should be defined in place of __x86_64__, just
that when -mx32 is used, __x32__ is additionally defined. simply as an
example, what i'm referring to could be accomplished by adding this to the
*cpp specs:
%{mx32:-D__x32__=1}
-mike
On Sun, Mar 20, 2011 at 10:53 PM, Mike Frysinger <[email protected]> wrote:
> On Monday, March 21, 2011 01:35:35 H.J. Lu wrote:
>> On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
>> > On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> >> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> >> > in looking at the gcc files, it doesnt seem like there's any defines
>> >> > setup to declare x32 directly. ?instead, you'd have to do something
>> >> > like: #ifdef __x86_64__
>> >> > # if __SIZEOF_LONG__ == 8
>> >> > /* x86_64 */
>> >> > # else
>> >> > /* x32 */
>> >> > # endif
>> >> > #endif
>> >> >
>> >> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
>> >> > from coming up with their own special/broken crap ? ?or are there some
>> >> > already that i'm not seeing ?
>> >>
>> >> The idea is in most cases, you only need to check __x86_64__ since x32
>> >> and x86-64 are very close. ?In some cases, x32 is very different from
>> >> x86_64, like assembly codes on long and pointer, you can check
>> >> __x86_64__ and __LP64__. In glibc, I used a different approach by using
>> >> macros REG_RAX, .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly
>> >> codes.
>> >
>> > while i agree with you in general that this is how people should be doing
>> > things, in practice i often see people fishing around. ?education only
>> > goes so far, so if there was an __x32__ define, i feel like people are
>> > more likely to get it right than wrong.
>> >
>> > i dont have any use cases off the top of my head, but i wouldnt be
>> > surprised if the heavy inline assembly people (like the multimedia peeps
>> > e.g. libav) approached it this way. ?rather than google for
>> > documentation, look at the cpp output between -m64 and -mx32 and see
>> > what sticks out. ?"__x32__" would certainly do that.
>>
>> My point is __x86_64__ version should work for both 64bit and x32. There
>> should no need for a separate x32 version.
>
> yes, and my point is that people often reach for cpp defines rather than
> figure out how to do it right.
>
> i'm not saying that __x32__ should be defined in place of __x86_64__, just
> that when -mx32 is used, __x32__ is additionally defined. ?simply as an
> example, what i'm referring to could be accomplished by adding this to the
> *cpp specs:
> ? ? ? ?%{mx32:-D__x32__=1}
I don't think it will help x32 and I think it will make it harder to
add x32 support.
I still want to see a real usage before I add it.
--
H.J.
Hi,
On Sun, 20 Mar 2011, H.J. Lu wrote:
> I don't think it will help x32 and I think it will make it harder to add
> x32 support. I still want to see a real usage before I add it.
% cat real-world.c
/* intptr_t; what's that? */
union space_saving_htab_element {
void *generic_pointer;
/* Usually we need a long for a pointer, but I just figured out
that on x32 an int is enough and smaller. My program
now needs half as much memory, supi! */
#ifdef __x32__
unsigned int as_number;
#else
unsigned long as_number;
#endif
};
Ciao,
Michael.
PS: Of course you and I wouldn't write such code, but Mikes point was that
there might be some that do. I could probably construct an example where
it would matter for real involving inline asm that for some reason has to
slightly differ depending on x32-ness.
On Mon, Mar 21, 2011 at 1:20 AM, Michael Matz <[email protected]> wrote:
> Hi,
>
> On Sun, 20 Mar 2011, H.J. Lu wrote:
>
>> I don't think it will help x32 and I think it will make it harder to add
>> x32 support. I still want to see a real usage before I add it.
>
> % cat real-world.c
> /* intptr_t; what's that? */
> union space_saving_htab_element {
> ?void *generic_pointer;
> ?/* Usually we need a long for a pointer, but I just figured out
> ? ? that on x32 an int is enough and smaller. ?My program
> ? ? now needs half as much memory, supi! ?*/
> #ifdef __x32__
> ?unsigned int as_number;
> #else
> ?unsigned long as_number;
> #endif
> };
That is the wrong way to support x32. You should remove "#ifdef __x32__",
which only shows __x32__ shouldn't be used/needed.
>
> Ciao,
> Michael.
> PS: Of course you and I wouldn't write such code, but Mikes point was that
> there might be some that do. ?I could probably construct an example where
> it would matter for real involving inline asm that for some reason has to
> slightly differ depending on x32-ness.
>
I am still waiting for a real example.
--
H.J.