ARM: Use different linker path for hardfloat ABI

On 3 April 2012 09:06, dann frazier <dann.frazier@canonical.com> wrote:
> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>> On 29/03/12 20:34, dann frazier wrote:
>> > This is an updated version of a patch Debian and Ubuntu are using to
>> > use an alternate linker path for hardfloat binaries. The difference
>> > with this one is that it covers the case where no float flag
>> > was passed in, defaulting to the softfloat path.

Hi Dann.  The change should be in the EABI specific linux-eabi.h
instead of the shared/OABI linux-elf.h.  It breaks support for uClibc
and Bionic by always using the GLIBC loader in hard float mode.  The
final line in the spec is missing a '=hard' and always adds
/lib/ld-linux.so.3.

How about:

2012-04-03  Michael Hope  <michael.hope@linaro.org>

       * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
       (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.


    use the GNU/Linux version, not the generic BPABI version.  */


which works for the following test cases:
 gcc -mhard-float foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
 gcc -mfloat-abi=hard foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
 gcc -msoft-float foo.c => /lib/ld-linux.so.3
 gcc -mfloat-abi=softfp foo.c => /lib/ld-linux.so.3
 gcc -mbionic => /system/bin/linker
 gcc -mbionic -mhard-float => /system/bin/linker
 gcc -muclibc => /lib/ld-uClibc.so.0
 gcc -muclibc -mhard-float => /lib/ld-uClibc.so.0

-- Michael

On Tue, Apr 03, 2012 at 03:29:06PM +1200, Michael Hope wrote:
> On 3 April 2012 09:06, dann frazier <dann.frazier@canonical.com> wrote:
> > On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> >> On 29/03/12 20:34, dann frazier wrote:
> >> > This is an updated version of a patch Debian and Ubuntu are using to
> >> > use an alternate linker path for hardfloat binaries. The difference
> >> > with this one is that it covers the case where no float flag
> >> > was passed in, defaulting to the softfloat path.
> 
> Hi Dann.  The change should be in the EABI specific linux-eabi.h
> instead of the shared/OABI linux-elf.h.  It breaks support for uClibc
> and Bionic by always using the GLIBC loader in hard float mode.  The
> final line in the spec is missing a '=hard' and always adds
> /lib/ld-linux.so.3.
> 
> How about:
> 
> 2012-04-03  Michael Hope  <michael.hope@linaro.org>
> 
>        * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
>        (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.

Nice, thanks Michael. I'd looked at doing something similar, but I
wasn't sure that defining GLIBC_DYNAMIC_LINKER to a spec macro would
work :)

     -dann
> 
> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> index 80bd825..8498472 100644
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -62,7 +62,12 @@
>  /* 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 \
> +   "%{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 "}}"
> 
>  /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
>     use the GNU/Linux version, not the generic BPABI version.  */
> 
> 
> which works for the following test cases:
>  gcc -mhard-float foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
>  gcc -mfloat-abi=hard foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
>  gcc -msoft-float foo.c => /lib/ld-linux.so.3
>  gcc -mfloat-abi=softfp foo.c => /lib/ld-linux.so.3
>  gcc -mbionic => /system/bin/linker
>  gcc -mbionic -mhard-float => /system/bin/linker
>  gcc -muclibc => /lib/ld-uClibc.so.0
>  gcc -muclibc -mhard-float => /lib/ld-uClibc.so.0
> 
> -- Michael

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.

(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.

(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.  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?  (The 
only previous relevant discussion that I recall is one on 
patches@eglibc.org starting at 
<http://www.eglibc.org/archives/patches/msg01017.html>, 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.)

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.

(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.

(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.  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), 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).

On Tue, Apr 03, 2012 at 10:56:18PM +0000, Joseph S. Myers wrote:
>
>(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.  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?  (The 
>only previous relevant discussion that I recall is one on 
>patches@eglibc.org starting at 
><http://www.eglibc.org/archives/patches/msg01017.html>, 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.)

Apologies, that was my fault - I was kept busy on other things and
didn't get back to that. At the time it didn't seem so critical when
we were still experimenting with other aspects of the system. I'll get
back to that shortly...

Cheers,

On Tue, Apr 3, 2012 at 6:56 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> (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.  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), 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).

The thread doesn't seem to be wrapping up, instead it appears to go in
circles :-)

As a glibc maintainer, when it comes to this issue, I am guided by:

(1) This is a distribution problem and the solution needs to come from
a consensus among the distributions.

(2) The gcc/glibc community should listen to the distributions.

The distributions have the most experience when it comes to
whole-system issues. I certainly don't have that experience.
Unfortunately *I* give the distributions a B- or C+ for communication.
Please make it easy for me to give you an A. It is exceedingly
difficult for me to review solutions that span multiple patches,
emails, mailing lists, and communities. The best way to avoid
rehashing old problems is to document the design and get sign off from
the interested parties.

If I see uncoordinated and conflicting responses from the
distributions... I get worried.

Is there a proposal on a wiki that begins to summarize the suggestions
and solution?

Cheers,
Carlos.