From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8242 invoked by alias); 27 Jun 2012 18:24:42 -0000 Received: (qmail 8110 invoked by uid 22791); 27 Jun 2012 18:24:39 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.lysator.liu.se (HELO mail.lysator.liu.se) (130.236.254.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Jun 2012 18:24:15 +0000 Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 33AE840004; Wed, 27 Jun 2012 20:24:14 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 2860940005; Wed, 27 Jun 2012 20:24:14 +0200 (CEST) X-Spam-Score: -1.2 Received: from [192.168.0.101] (h-149-24.a163.priv.bahnhof.se [81.170.149.24]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C449640004; Wed, 27 Jun 2012 20:24:11 +0200 (CEST) Message-ID: <1340821451.5127.11.camel@sara> Subject: Re: [x86-64 psABI] RFC: Extend x86-64 psABI to support x32 From: Magnus Fromreide To: "H.J. Lu" Cc: x32-abi@googlegroups.com, discuss@x86-64.org, GCC Development , Binutils , GNU C Library , GDB Date: Wed, 27 Jun 2012 18:24:00 -0000 In-Reply-To: References: <69b1606d-6150-46eb-a426-93bfad19e7a2@googlegroups.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00091.txt.bz2 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? 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