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

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Jun 27, 2012 at 11:24 AM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> On Wed, 2012-06-27 at 05:01 -0700, H.J. Lu wrote:
>> On Tue, Jun 26, 2012 at 10:56 PM, Mark Butler <butlerm@middle.net> wrote:
>> >
>> >
>> > 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?
>> >
>>
>> We changed it to
>>
>> struct timespec
>>   {
>>     __time_t tv_sec;          /* Seconds.  */
>>     __syscall_slong_t tv_nsec;        /* Nanoseconds.  */
>>   };
>>
>
> 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.