From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1225 invoked by alias); 18 Feb 2011 20:32:23 -0000 Received: (qmail 1075 invoked by uid 22791); 18 Feb 2011 20:32:22 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Feb 2011 20:32:16 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 7A1C39AC7D4; Fri, 18 Feb 2011 21:32:14 +0100 (CET) Date: Fri, 18 Feb 2011 20:32:00 -0000 From: Jan Hubicka To: "H.J. Lu" Cc: Jan Beulich , GCC Development , x32-abi@googlegroups.com, Jakub Jelinek , Binutils , GNU C Library , Jan Hubicka , "H. Peter Anvin" Subject: Re: x32 psABI draft version 0.2 Message-ID: <20110218203214.GB5354@kam.mff.cuni.cz> References: <4D5CEBDE02000078000325A2@vpn.id2.novell.com> <20110217142916.GI13037@sunsite.ms.mff.cuni.cz> <20110217152233.GB11346@atrey.karlin.mff.cuni.cz> <20110217154452.GA18799@kam.mff.cuni.cz> <4D5D56B70200007800032747@vpn.id2.novell.com> <4D5E37C702000078000329DE@vpn.id2.novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00244.txt.bz2 > On Fri, Feb 18, 2011 at 12:11 AM, Jan Beulich wrote: > >>>> On 17.02.11 at 18:59, "H.J. Lu" wrote: > >> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote: > >>>>>> On 17.02.11 at 16:49, "H.J. Lu" wrote: > >>>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote: > >>>>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads > >>>>>> > to significandly smaller libxul.so size > >>>>>> > > >>>>>> > According to http://glandium.org/blog/?p=1177 the difference is about 4-5MB > >>>>>> > (out of approximately 20-30MB shared lib) > >>>>>> > >>>>>> This is orthogonal to x32 psABI. > >>>>> > >>>>> Understood.  I am just pointing out that x86-64 Mozilla suffers from startup > >>>>> problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI > >>>>> because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we > >>>>> would not have this problem here. > >>>>> > >>>> > >>>> If people want to see REL+RELA in x32, they have to contribute codes. > >>> > >>> That's exactly the wrong way round: First the specification has to allow > >>> for (but not require) it, and only then does it make sense to write code. > >>> > >> > >> No, it has to be supported at least by static linker and dynamic > >> linker. Otherwise, no one can use it. > > > > I'm afraid I have to disagree: ELF (and the psABI) is not specific to > > a particular OS, and hence it allowing something doesn't mean the > > OS ABI may not restrict it. Hence the psABI first has to at least not > > forbid something (as it currently does for REL on x86-64), in order > > for an implementation of that something to make sense. > > > > Jan > > > > > > How about only allowing REL relocations in executables and DSOes? I don't know, I am not really expert in this area. So I am not quit sure if allowing REL is good idea given the mess they imply in binutils sources. I guess it makes sense supposing that it is easy for linker to turn RELAs at input with addend fitting range into RELs. I wondered, based on the Mozilla experience, if we don't want to make REL optional in x86-64 ABI, too? Honza