From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27606 invoked by alias); 5 Apr 2012 01:17:05 -0000 Received: (qmail 27587 invoked by uid 22791); 5 Apr 2012 01:17:02 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 01:16:49 +0000 Received: by wibhj13 with SMTP id hj13so829336wib.12 for ; Wed, 04 Apr 2012 18:16:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=jdLsZky33WZpejaCaSBdpoOKd7MsJfKuokbXXJI/0L4=; b=d7ShEi6oU/0ggOhWReWDDuybnGmiZBfi2gAVycE44HgYwq6CgXShWWAWvV2U1k/gBY /jEI4Jdp38/HlhmZqPRymd4ibmbDz68TDsQ1MvBHZsxRzZbumAMJD+0oXUX9FPcKLUjt tKhRjiQaYL0jaMTUG1+o1UWSokL+i0rhBnHCOaZDBb5+AZBeOw65SUvdBPnuBD0pIyLo EDG50+tV4DavPCngfGIM3ScWL8/PKvxUDd1ZuBgMnZfK+Girsu7XUe6k0uFUhimg6OXx aZQTvYsqgnUm5UCls1SJsa9zoocgdQVADRtCk9p65+Fl6n/pQ7TEKcwQheuWacFYDqbq Km9w== Received: by 10.180.94.33 with SMTP id cz1mr148550wib.13.1333588607590; Wed, 04 Apr 2012 18:16:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.7.206 with HTTP; Wed, 4 Apr 2012 18:16:27 -0700 (PDT) In-Reply-To: References: <20120329193401.GA14860@dannf.org> <4F75F2E2.3030909@arm.com> <20120402210653.GC28152@dannf.org> From: Michael Hope Date: Thu, 05 Apr 2012 01:17:00 -0000 Message-ID: Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI To: "Joseph S. Myers" Cc: dann frazier , Richard Earnshaw , "cross-distro@lists.linaro.org" , "gcc-patches@gcc.gnu.org" , libc-ports@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmeBHsC+AZDeu/R1giJDyUQKIEB77U0ZFEh1p1g4l0v3I75BpL1GqODWaSrjo1gRmASYxRK X-IsSubscribed: yes 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/msg00007.txt.bz2 On 5 April 2012 12:07, Joseph S. Myers wrote: > On Thu, 5 Apr 2012, Michael Hope wrote: > >> > I don't think that's appropriate for ABI issues. =A0If a different dyn= amic >> > linker name is specified, GCC should use it unconditionally (and requi= re >> > new enough glibc or a glibc installation that was appropriately >> > rearranged). >> >> OK. =A0I want GCC 4.7.1 to use the new path. =A0Does this mean that >> released versions of GLIBC and GCC 4.7.1 will be incompatible, or does >> GLIBC pick the path up from GCC? > > Released versions would be incompatible (you could make GCC check at > configure time for too-old glibc if --with-float=3Dhard); the path needs > hardcoding in both places. > >> >> Do the MIPS or PowerPC loaders detect the ABI and change the library >> >> path based on that? =A0I couldn't tell from the code. >> > >> > No, they don't detect the ABI. =A0Both ABIs (and, for Power, the e500v= 1 and >> > e500v2 variants - compatible with soft-float at the function-calling l= evel >> > but with some glibc ABI differences with soft-float and with each othe= r) >> > use the same directories. >> >> Sorry, I'm confused. =A0I had a poke about with MIPS and it uses >> different argument registers for soft and hard float. =A0Soft float uses >> $4 and hard float $f0. =A0Are there shims or similar installed by the >> loader? > > No. =A0A system is either purely hard-float or purely soft-float, and the > same paths are used for both so they can't coexist. =A0(Mismatches at > *static* link time are detected through object attributes.) Ah, the same as ARM then. The MIPS community would need something similar to this patch if they wanted to support soft and hard float side by side. >> Big endian is extremely uncommon on ARM and I'd rather define it when >> needed. =A0For strictness sake I'll change the patch to use the new path >> for hard float little endian only. > > I don't think that's correct; the new path should be used independent of > endian, just as the existing path is. OK. >=A0But any multiarch support patch > should presumably define separate multiarch paths for each endianness. That's up to Debian. I've asked for documentation on the final tuples and what they mean as the one at: http://wiki.debian.org/Multiarch/Tuples is out of date. I prefer defining what is needed now and doing others as needed. -- Michael