[x86-64 psABI] RFC: Extend x86-64 psABI to support x32

[H.J. Lu]

Hi,

Support for the x32 psABI:

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

is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64
instruction set with size of long and pointers == 4 bytes. X32 is
already supported in GCC 4.7.0 and binutils 2.22. I am now working
to integrate x32 support into GLIBC 2.16 and GDB 7.5 Here is a
patch to extend x86-64 psABI for x32. Any comments?

Thanks.

--
H.J.

[H. Peter Anvin]

As a minor nitpick, I have always used x32 with a lower case x. The
capital X32 looks odd to me.

-hpa

[H.J. Lu]

I used X32 together with LP64. I can use ILP32 instead of X32 when
LP64 is mentioned at the same time.

--
H.J.

[H.J. Lu]

On Tue, May 15, 2012 at 9:07 AM, Michael Matz <ma...@suse.de> wrote:
> Hi,

>
> On Mon, 14 May 2012, H.J. Lu wrote:
>
>> > As a minor nitpick, I have always used x32 with a lower case x.  The
>> > capital X32 looks odd to me.
>> >
>>
>> I used X32 together with LP64.  I can use ILP32 instead of X32 when LP64
>> is mentioned at the same time.
>

> I'd prefer that.  x32 is a nice short-hand name for the whole thing, but
> not descriptive, unlike LP64.  So, yes, IMO it should be ILP32 in the ABI
> document.
>

I will make the change and post a new patch.

Thanks.

--
H.J.

[H.J. Lu]

On Tue, May 15, 2012 at 9:07 AM, Michael Matz <ma...@suse.de> wrote:
> Hi,
>
> On Mon, 14 May 2012, H.J. Lu wrote:
>

>> > As a minor nitpick, I have always used x32 with a lower case x.  The
>> > capital X32 looks odd to me.
>> >
>>
>> I used X32 together with LP64.  I can use ILP32 instead of X32 when LP64
>> is mentioned at the same time.
>

> I'd prefer that.  x32 is a nice short-hand name for the whole thing, but
> not descriptive, unlike LP64.  So, yes, IMO it should be ILP32 in the ABI
> document.
>

Here is the updated change. Any comments?

Thanks.



--
H.J.

[Mark Butler]

On Monday, May 14, 2012 11:31:11 AM UTC-6, H.J. wrote: 

Support for the x32 psABI:

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

is added in Linux kernel 3.4-rc1.  X32 uses the ILP32 model for x86-64
instruction set with size of long and pointers == 4 bytes.  X32 is

already supported in GCC 4.7.0 and binutils 2.22...Here is a

patch to extend x86-64 psABI for x32.  Any comments?

May I ask why the decision was made to use ILP32 instead of L64P32?   The latter would seem to avoid lots of porting problems in particular.  And if porting difficulties are the major complained about x32, is it really too late to switch?  Thanks - mdb

[H.J. Lu]

x32 is designed to replace ia32 where long is 32-bit, not x86-64.


--
H.J.

[H. Peter Anvin]

On 06/26/2012 12:47 PM, H.J. Lu wrote:
>>
>> May I ask why the decision was made to use ILP32 instead of L64P32? The
>> latter would seem to avoid lots of porting problems in particular. And if
>> porting difficulties are the major complained about x32, is it really too
>> late to switch? Thanks - mdb
>
> x32 is designed to replace ia32 where long is 32-bit, not x86-64.
>

It's worth noting that there are *no* Linux platforms that are not ILP32
or LP64, so adding a third memory model is likely to cause even more
problems...

-hpa

[Mark Butler]

x32 is designed to replace ia32 where long is 32-bit, not x86-64.

I understand, but wouldn't L64P32 be much better in the long run? In terms of compatibility with LP64, and an LP64 kernel in particular?  The structure layouts of any structure that did not contain pointers would be identical, for example.  struct timeval, struct timespec, struct stat, and on and on...

[H.J. Lu]

Linux/x32 uses the same layout for struct timeval, struct timespec, struct stat,
as Linux/x86-64. It is orthogonal to L64 vs L32.

--
H.J.

[Mark Butler]

On Tuesday, June 26, 2012 3:22:45 PM UTC-6, H.J. wrote:

On Tue, Jun 26, 2012 at 2:11 PM, Mark Butler wrote:
>
>> x32 is designed to replace ia32 where long is 32-bit, not x86-64.
>>
> I understand, but wouldn't L64P32 be much better in the long run? In terms
> of compatibility with LP64, and an LP64 kernel in particular?  The structure
> layouts of any structure that did not contain pointers would be identical,
> for example.  struct timeval, struct timespec, struct stat, and on and on...

Linux/x32 uses the same layout for struct timeval, struct timespec, struct stat,
as Linux/x86-64. It is orthogonal to L64 vs L32.

If POSIX requires struct timespec to look like this:

struct timespec {

  time_t tv_sec;

  long   tv_nsec;

}

then how can an ABI with 32 bit longs have the same struct timespec layout as an ABI with 64 bit longs?
 

[H.J. Lu]

We changed it to

struct timespec
{
__time_t tv_sec; /* Seconds. */
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};


--
H.J.

[H.J. Lu]

On Wed, Jun 27, 2012 at 11:24 AM, Magnus Fromreide <ma...@lysator.liu.se> wrote:

> I think that means you fails to conform to posix unless
> __syscall_slong_t is an alias for long.

That is true.

> If I understand the posix spec correctly then, in a conforming
> implementation,
>
> struct timespec ts;
> if (sizeof(long) != sizeof(ts.tv_nsec))
>  abort();
>
> never calls abort.

It will abort on x32.

> For your purpose it would have been much better if tv_nsec had been
> specified with a type with allowed values, similarly to how suseconds_t
> that is used for timeval.tv_usec is specified.
>
> I suppose this is something to bring up for posix-next.
>

Yes, that is the intention.


--
H.J.

[Mark Butler]

On Tuesday, June 26, 2012 1:53:01 PM UTC-6, H. Peter Anvin wrote:

It's worth noting that there are *no* Linux platforms that are not ILP32
or LP64, so adding a third memory model is likely to cause even more
problems...

Care to comment on what sort of things would be likely to cause a large number of problems porting to an L64P32 model?  I understand that L32P64 (as in Windows 64 bit) causes lots of problems, because there is a lot of code that assumes that a pointer can be converted to a long and back.  That would not be a problem with L64P32 however, because there pointers would be smaller than longs rather than larger.

[H. Peter Anvin]

Every time you introduce a new model you will have problems, but in
Linux it is a strong assumption that sizeof(long) == sizeof(void *).

-hpa


--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.