From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23701 invoked by alias); 31 Dec 2010 18:20:45 -0000 Received: (qmail 23683 invoked by uid 22791); 31 Dec 2010 18:20:44 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 31 Dec 2010 18:20:40 +0000 Received: by qwa26 with SMTP id 26so11837673qwa.0 for ; Fri, 31 Dec 2010 10:20:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.10.208 with SMTP id q16mr17196125qaq.65.1293819638424; Fri, 31 Dec 2010 10:20:38 -0800 (PST) Received: by 10.220.190.137 with HTTP; Fri, 31 Dec 2010 10:20:38 -0800 (PST) In-Reply-To: References: <20101230182308.GA21296@intel.com> <20101230195759.GU16156@tyan-ft48-01.lab.bos.redhat.com> <4D1CFCAD.5080804@zytor.com> <20101231100339.GV16156@tyan-ft48-01.lab.bos.redhat.com> Date: Fri, 31 Dec 2010 18:43:00 -0000 Message-ID: Subject: Re: RFC: Add 32bit x86-64 support to binutils From: "H.J. Lu" To: Jakub Jelinek , discuss@x86-64.org Cc: "H. Peter Anvin" , Richard Guenther , "Joseph S. Myers" , binutils@sourceware.org, gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00707.txt.bz2 On Fri, Dec 31, 2010 at 8:50 AM, H.J. Lu wrote: > On Fri, Dec 31, 2010 at 2:03 AM, Jakub Jelinek wrote: >> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote: >>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote: >>> >> >>> >> Would be nice if LFS would be mandatory on the new ABI, thus >>> >> off_t being 64bits. >>> > >>> > And avoid ambiguous cases that x86-64 ABI has, e.g. whether >>> > caller or callee is responsible for sign/zero extension of arguments,= to >>> > avoid the need to sign/zero extend twice, etc. >>> > >>> >>> Ehwhat? =A0x86-64 is completely unambiguous on that point; the i386 one= is >>> not. >> >> It is not, sadly, see http://gcc.gnu.org/PR46942 >> From what I can see the psABI doesn't talk about it, GCC usually sign/ze= ro >> extends on both sides (exception is 32-bit arguments into 64-bit isn't >> apparently sign/zero extended on the caller side when doing tail calls), >> from what I gathered LLVM expects the caller to sign/zero extend (which = is >> incompatible with GCC tail calls then), not sure about ICC, and kernel >> probably expects for security reasons that the callee sign/zero extends. >> >> =A0 =A0 =A0 =A0Jakub >> > > I added > > --- > When a value of type signed/unsigned char or short is returned or passed > in a register or on the stack, it should be sign/zero extended to > signed/unsigned > int. > --- > > to hjl/extension branch at > > http://git.kernel.org/?p=3Ddevel/binutils/hjl/x86-64-psabi.git;a=3Dsummary > According to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D42324 all compilers clears bits 1-31 when passing _Bool to a function. Also GCC doesn't sign/zero extend on char/short return. I updated x86-64 psABI to ---- When a value of type _Bool is returned in a register, bit 0 contains the tr= uth value and bits 1 to 7 shall be zero. When an argument of type _Bool is pass= ed in a register or on the stack, bit 0 contains the truth value and bits 1 to 31 shall be zero. When a value of type signed/unsigned char or short is returned in a registe= r, bits 0 to 7 for char and bits 0 to 15 for short contain the value and other bits are left unspecified. When an argument of signed/unsigned type char or short is passed in a register or on the stack, it shall be sign/zero extend= ed to signed/unsigned int. --- on hjl/extension branch at http://git.kernel.org/?p=3Ddevel/binutils/hjl/x86-64-psabi.git;a=3Dsummary --=20 H.J.