From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18917 invoked by alias); 17 Feb 2011 08:35:37 -0000 Received: (qmail 18806 invoked by uid 22791); 17 Feb 2011 08:35:36 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_IB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from vpn.id2.novell.com (HELO vpn.id2.novell.com) (195.33.99.129) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Feb 2011 08:35:31 +0000 Received: from EMEA1-MTA by vpn.id2.novell.com with Novell_GroupWise; Thu, 17 Feb 2011 08:35:30 +0000 Message-Id: <4D5CEBDE02000078000325A2@vpn.id2.novell.com> Date: Thu, 17 Feb 2011 08:35:00 -0000 From: "Jan Beulich" To: "H.J. Lu" ,"H. Peter Anvin" Cc: "GCC Development" ,, "Binutils" , "GNU C Library" Subject: Re: x32 psABI draft version 0.2 References: <4D5C2DD2.10608@zytor.com> In-Reply-To: <4D5C2DD2.10608@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: 2011-02/txt/msg00204.txt.bz2 >>> On 16.02.11 at 21:04, "H. Peter Anvin" wrote: > On 02/16/2011 11:22 AM, H.J. Lu wrote: >> Hi, >>=20 >> I updated x32 psABI draft to version 0.2 to change x32 library path >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, >> Ubuntu and other derivative distributions. The new x32 psABI is >> available from: >>=20 >> https://sites.google.com/site/x32abi/home=20 >>=20 >=20 > I'm wondering if we should define a section header flag (sh_flags) > and/or an ELF header flag (e_flags) for x32 for the people unhappy about > keying it to the ELF class... Thanks for supporting this! Besides that I also wonder why all the 64-bit relocations get marked as LP64-only. It is clear that some of them can be useful in ILP32 as well, and there's no reason to preclude future uses even if currently no-one can imagine any. Furthermore, it seems questionable to continue to require rela relocations when for all normal ones (leaving aside the 8- and 16- bit ones) the addend can fit in the relocated field. Finally, shouldn't R_X86_64_GLOB_DAT and R_X86_64_JUMP_SLOT also have a field specifier of wordclass rather than word64 (though 'wordclass' by itself would probably be wrong if the tying of the ABI to the ELF class was eliminated)? And how about R_X86_64_*TP*64 and R_X86_64_TLSDESC? Jan