X32 psABI status update

X32 psABI status update

[H.J. Lu]

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.

Re: X32 psABI status update

[H.J. Lu]

On Sat, Mar 5, 2011 at 11:08 AM, H.J. Lu <hjl.tools@gmail.com> 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.

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 476 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[H.J. Lu]

On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger <vapier@gentoo.org> 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.

X32 psABI status update

[H.J. Lu]

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.

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 750 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[H.J. Lu]

On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger <vapier@gentoo.org> 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.

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1849 bytes --]

On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> 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, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: X32 psABI status update

[H.J. Lu]

On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger <vapier@gentoo.org> 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.

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1217 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[H.J. Lu]

On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <vapier@gentoo.org> 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.

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1861 bytes --]

On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[H.J. Lu]

On Wed, Mar 16, 2011 at 10:45 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <vapier@gentoo.org> 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.

Re: X32 psABI status update

[Richard Henderson]

On 03/16/2011 10:21 PM, H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <vapier@gentoo.org> 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~

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1574 bytes --]

On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[H.J. Lu]

On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger <vapier@gentoo.org> 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.

Re: X32 psABI status update

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2271 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: X32 psABI status update

[H.J. Lu]

On Sun, Mar 20, 2011 at 10:53 PM, Mike Frysinger <vapier@gentoo.org> 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.

Re: X32 psABI status update

[Michael Matz]

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.

Re: X32 psABI status update

[H.J. Lu]

On Mon, Mar 21, 2011 at 1:20 AM, Michael Matz <matz@suse.de> 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.

Re: x32 psABI status update

[H.J. Lu]

More data

    * 186.crafty from SPEC CPU 2000 (64bit integer):
          o Intel Core i7
                + ~5% slower than x86-64.
                + ~29% faster than ia32.
                + Sizes in bytes:

                           text       data        bss        dec
 hex    filename
                     200519      16388    1068916    1285823
139ebf    crafty.32
                     172389      16868    1069784    1259041
133621    crafty.64
                     174723      16564    1068916    1260203
133aab    crafty.x32

          o Intel Atom
                + ~6% slower than x86-64.
                + ~7% faster than ia32.
                + Sizes in bytes:

                       text       data        bss        dec
hex    filename
                 199339      16388    1068916    1284643     139a23    crafty.32
                 171157      16868    1069784    1257809     133151    crafty.64
                 173535      16564    1068916    1259015     133607
crafty.x32

H.J.
---
On Sat, Feb 19, 2011 at 11:23 AM, Xinliang David Li <davidxl@google.com> wrote:
> This shows how important ilp32 is for some applications. It would be good to
> show the impact of larger register set. Candidates are those spec programs
> which are slower with ia32.
>
> David
>
> On Feb 19, 2011 10:14 AM, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> On Fri, Feb 18, 2011 at 8:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I updated  x32 psABI draft to version 0.2 to change x32 library path
>>>>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>>>>> Ubuntu and other derivative distributions. The new x32 psABI is
>>>>> available from:
>>>>>
>>>>> https://sites.google.com/site/x32abi/home
>>>>>
>>>>
>>>> Initial kernel, glibc and gcc port for x32 psABI draft version 0.2  is
>>>> done:
>>>>
>>>> 1. Kernel should be very stable.  Fedora 14 kernel patch is also
>>>> available.
>>>> 2. Need to fix GCC run-time libraries.
>>>> 3. Need to fix glibc tests.
>>>>
>>>> Please check them out and provide feed backs.
>>>
>>> I updated x32 website:
>>>
>>> https://sites.google.com/site/x32abi/
>>>
>>> with "get started" instructions.
>>>
>>
>> I update the x32 website
>>
>> https://sites.google.com/site/x32abi/
>>
>> with data on mcf in SPEC CPU 2K:
>>
>> * 181.mcf from SPEC CPU 2000:
>> o Intel Core i7
>> + ~32% faster than x86-64.
>> + ~1% slower than ia32.
>> + Sizes in bytes:
>>
>> text data bss dec
>> hex filename
>> 12155 336 7036 19527
>> 4c47 mcf.32
>> 12421 664 13568 26653
>> 681d mcf.64
>> 11583 412 7040 19035
>> 4a5b mcf.x32
>>
>> o Intel Atom
>> + ~28% faster than x86-64.
>> + ~0.5% slower than ia32.
>> + Sizes in bytes:
>>
>> text data bss dec
>> hex filename
>> 12059 336 7036 19431
>> 4be7 mcf.32
>> 12341 664 13568 26573
>> 67cd mcf.64
>> 11411 412 7040 18863
>> 49af mcf.x32
>>
>>
>> --
>> H.J.
>



-- 
H.J.

Re: x32 psABI status update

[H.J. Lu]

On Fri, Feb 18, 2011 at 8:28 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> Hi,
>>>
>>> I updated  x32 psABI draft to version 0.2 to change x32 library path
>>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>>> Ubuntu and other derivative distributions. The new x32 psABI is
>>> available from:
>>>
>>> https://sites.google.com/site/x32abi/home
>>>
>>
>> Initial kernel, glibc and gcc port for x32 psABI draft version 0.2  is done:
>>
>> 1. Kernel should be very stable.  Fedora 14 kernel patch is also available.
>> 2. Need to fix GCC run-time libraries.
>> 3. Need to fix glibc tests.
>>
>> Please check them out and provide feed backs.
>
> I updated x32 website:
>
> https://sites.google.com/site/x32abi/
>
> with "get started" instructions.
>

I update the x32 website

https://sites.google.com/site/x32abi/

with data on mcf in SPEC CPU 2K:

    * 181.mcf from SPEC CPU 2000:
          o Intel Core i7
                + ~32% faster than x86-64.
                + ~1% slower than ia32.
                + Sizes in bytes:

                           text       data        bss        dec
 hex    filename
                       12155        336       7036      19527
4c47    mcf.32
                       12421        664      13568      26653
681d    mcf.64
                       11583        412       7040      19035
4a5b    mcf.x32

          o Intel Atom
                + ~28% faster than x86-64.
                + ~0.5% slower than ia32.
                + Sizes in bytes:

                           text       data        bss        dec
 hex    filename
                        12059        336       7036      19431
4be7    mcf.32
                        12341        664      13568      26573
67cd    mcf.64
                        11411        412       7040      18863
49af    mcf.x32


-- 
H.J.

Re: x32 psABI status update

[H.J. Lu]

On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> Hi,
>>
>> I updated  x32 psABI draft to version 0.2 to change x32 library path
>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>> Ubuntu and other derivative distributions. The new x32 psABI is
>> available from:
>>
>> https://sites.google.com/site/x32abi/home
>>
>
> Initial kernel, glibc and gcc port for x32 psABI draft version 0.2  is done:
>
> 1. Kernel should be very stable.  Fedora 14 kernel patch is also available.
> 2. Need to fix GCC run-time libraries.
> 3. Need to fix glibc tests.
>
> Please check them out and provide feed backs.

I updated x32 website:

https://sites.google.com/site/x32abi/

with "get started" instructions.

-- 
H.J.

x32 psABI status update

[H.J. Lu]

On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> Hi,
>
> I updated  x32 psABI draft to version 0.2 to change x32 library path
> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> Ubuntu and other derivative distributions. The new x32 psABI is
> available from:
>
> https://sites.google.com/site/x32abi/home
>

Initial kernel, glibc and gcc port for x32 psABI draft version 0.2  is done:

1. Kernel should be very stable.  Fedora 14 kernel patch is also available.
2. Need to fix GCC run-time libraries.
3. Need to fix glibc tests.

Please check them out and provide feed backs.

Thanks.


-- 
H.J.