From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14967 invoked by alias); 27 Jun 2012 18:29:32 -0000 Received: (qmail 14865 invoked by uid 22791); 27 Jun 2012 18:29:30 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Jun 2012 18:29:17 +0000 Received: by qcsd16 with SMTP id d16so776350qcs.14 for ; Wed, 27 Jun 2012 11:29:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.59.19 with SMTP id j19mr3541516qah.25.1340821756256; Wed, 27 Jun 2012 11:29:16 -0700 (PDT) Received: by 10.229.192.129 with HTTP; Wed, 27 Jun 2012 11:29:16 -0700 (PDT) In-Reply-To: <1340821451.5127.11.camel@sara> References: <69b1606d-6150-46eb-a426-93bfad19e7a2@googlegroups.com> <1340821451.5127.11.camel@sara> Date: Wed, 27 Jun 2012 18:29:00 -0000 Message-ID: Subject: Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32 From: "H.J. Lu" To: Magnus Fromreide Cc: x32-abi@googlegroups.com, discuss@x86-64.org, GCC Development , Binutils , GNU C Library , GDB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00092.txt.bz2 On Wed, Jun 27, 2012 at 11:24 AM, Magnus Fromreide w= rote: > On Wed, 2012-06-27 at 05:01 -0700, H.J. Lu wrote: >> On Tue, Jun 26, 2012 at 10:56 PM, Mark Butler 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? =A0The >> >> > structure >> >> > layouts of any structure that did not contain pointers would be >> >> > identical, >> >> > for example. =A0struct timeval, struct timespec, struct stat, and o= n and >> >> > on... >> >> >> >> Linux/x32 uses the same layout for struct timeval, struct timespec, s= truct >> >> stat, >> >> as Linux/x86-64. It is orthogonal to L64 vs L32. >> >> >> > If POSIX requires struct timespec to look like this: >> > >> > struct timespec { >> > =A0 time_t tv_sec; >> > =A0 long =A0 tv_nsec; >> > } >> > >> > then how can an ABI with 32 bit longs have the same struct timespec la= yout >> > as an ABI with 64 bit longs? >> > >> >> We changed it to >> >> struct timespec >> =A0 { >> =A0 =A0 __time_t tv_sec; =A0 =A0 =A0 =A0 =A0/* Seconds. =A0*/ >> =A0 =A0 __syscall_slong_t tv_nsec; =A0 =A0 =A0 =A0/* Nanoseconds. =A0*/ >> =A0 }; >> > > 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) !=3D sizeof(ts.tv_nsec)) > =A0abort(); > > 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. --=20 H.J.