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.

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

[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

[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."

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.

X32 syscall number base

[Mike Frysinger]

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

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

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