This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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.

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.

/MF


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]