From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4382 invoked by alias); 5 Apr 2012 01:32:56 -0000 Received: (qmail 4358 invoked by uid 22791); 5 Apr 2012 01:32:54 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_BH,TW_IB X-Spam-Check-By: sourceware.org Received: from complete.lackof.org (HELO complete.lackof.org) (198.49.126.79) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 01:32:40 +0000 Received: from fluid.dannf (localhost [127.0.0.1]) by complete.lackof.org (Postfix) with ESMTP id 2FA7A33E00B5; Wed, 4 Apr 2012 19:32:38 -0600 (MDT) Received: by fluid.dannf (Postfix, from userid 1000) id B47ACA00B8; Wed, 4 Apr 2012 19:32:38 -0600 (MDT) Date: Thu, 05 Apr 2012 01:32:00 -0000 From: dann frazier To: Michael Hope Cc: "Joseph S. Myers" , Richard Earnshaw , "cross-distro@lists.linaro.org" , "gcc-patches@gcc.gnu.org" , libc-ports@sourceware.org Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI Message-ID: <20120405013238.GF29588@dannf.org> References: <20120329193401.GA14860@dannf.org> <4F75F2E2.3030909@arm.com> <20120402210653.GC28152@dannf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00008.txt.bz2 On Wed, Apr 04, 2012 at 02:39:58PM +1200, Michael Hope wrote: > On 4 April 2012 10:56, Joseph S. Myers wrote: > > On Tue, 3 Apr 2012, Michael Hope wrote: > > > >> +#define GLIBC_DYNAMIC_LINKER \ > >> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ > >> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ > >> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}" > > > > (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to > > be handled in specs. > > Fixed. > > > (b) You need to handle compilers configured with --with-float=hard, so > > make the specs depend on the default ABI the compiler was configured with. > > GCC seems to take configure time options into account when evaluating > a spec file. > > Tested by building a default, --with-float=hard, and > --with-float=softfp compiler then checking the loader path for all > combinations of {,-mglibc,-mbionic,-muclibc} x > {,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}. > > > (c) Please include libc-ports on future submissions and provide both the > > GCC patch and the glibc ports patch that have been tested to work together > > to build and install the library in the given path; a patch to one > > component like this cannot sensibly be considered in isolation.  I imagine > > you'll need appropriate ARM preconfigure support to detect what ABI the > > compiler is using, much like the support for MIPS, so that the right > > shlib-versions files are used. > > Agreed. > > >  I try to follow all ARM glibc discussions > > on libc-ports closely, as the ARM glibc maintainer; was there a previous > > discussion of the dynamic linker naming issue there that I missed? > > Steve McIntyre is driving this inside Debian. I'll ping him on the > GLIBC support. > > The tricky one is new GCC with old GLIBC. GCC may have to do a > configure time test and fall back to /lib/ld-linux.so.3 if the hard > float loader is missing. > > >  (The only previous relevant discussion that I recall is one on > > patches@eglibc.org starting at > > , regarding how the > > dynamic linker should check that a library has the right ABI, and there > > was no real followup on that after I indicated what would seem to be the > > appropriate implementation approaches and places for subsequent > > discussion.) > > The patch above changes the loader to catch a mixed installation and > reject mixing incompatible libraries. The static linker does this > currently but it's not essential. > > > I have no idea whether shlib-versions files naming a file in a > > subdirectory will work - but if not, you'd need to send a patch to > > libc-alpha to support dynamic linkers in subdirectories, with appropriate > > justification for why you are doing something different from all other > > architectures. > > Understood. For now this is just a path. There's more infrastructure > work needed if the path includes a directory. > > > (d) Existing practice for Power Architecture and MIPS at least is that > > hard-float and soft-float *don't* use different library directories / > > dynamic linkers. > > The goal is to have a standard loader path for all hard float distros > and, similar to how you can have a mixed 32/64 bit installation, allow > mixed softfp/hard float installations for distros that want it. This > is a new requirement and ARM is the first one exposed to it. I assume > Debian would push for similar changes on MIPS and PowerPC. > > Do the MIPS or PowerPC loaders detect the ABI and change the library > path based on that? I couldn't tell from the code. > > > (e) Existing practice for cases that do use different dynamic linkers is > > to use a separate library directory, not just dynamic linker name, as in > > lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to > > make two sets of libraries work in parallel if you have separate library > > directories like that. > > Is this required, or should it be left to the distro to choose? Once > the loader is in control then it can account for any distro specific > features, which may be the standard /lib and /usr/lib for single ABI > distros like Fedora or /usr/lib/$tuple for multiarch distros like > Ubuntu and Debian. > > > So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to > > handle that directory, I think) > > I'd like to leave that discussion for now. The Debian goal is to > support incompatible ABIs and, past that, incompatible architectures. > libhf is ambiguous as you could have a MIPS hard float library > installed on the same system as an ARM hard float library. > > > and these different Debian-style names > > could be implemented separately in a multiarch patch if someone submits > > one that properly accounts for my review comments on previous patch > > versions (failure to produce such a fixed patch being why Debian multiarch > > directory support has not got into GCC so far). > > Agreed. Note that this loader path discussion is unrelated to > multiarch. It came from the same people so there's a family > resemblance. > > (BTW Dann, apologies for stealing your patch) s/stealing/improving upon/ :) No worries, it is appreciated. > -- Michael > > 2012-04-03 Michael Hope > > * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define. > (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path. > > diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h > index 80bd825..8c9d2e7 100644 > --- a/gcc/config/arm/linux-eabi.h > +++ b/gcc/config/arm/linux-eabi.h > @@ -62,7 +62,11 @@ > /* Use ld-linux.so.3 so that it will be possible to run "classic" > GNU/Linux binaries on an EABI system. */ > #undef GLIBC_DYNAMIC_LINKER > -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3" > +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3" > +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT > "/lib/arm-linux-gnueabihf/ld-linux.so.3" > +#define GLIBC_DYNAMIC_LINKER \ > + "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \ > + %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}" > > /* At this point, bpabi.h will have clobbered LINK_SPEC. We want to > use the GNU/Linux version, not the generic BPABI version. */