Re: [PATCH 2/3] Fix LIBC_PROG_BINUTILS for -fuse-ld=lld

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 26/10/2021 17:48, Fangrui Song wrote:
> 
> On 2021-10-26, Adhemerval Zanella wrote:
>> GCC does not print the correct linker when -fuse-ld=lld is used with
>> the -print-prog-name=ld:
>>
>>  $ gcc -v 2>&1 | tail -n 1
>>  gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)
>>  $ gcc
>>  ld
>>
>> This is different than for gold:
>>
>>  $ gcc -fuse-ld=gold -print-prog-name=ld
>>  ld.gold
> 
> I think it may be debatable whether -fuse-ld={bfd,gold,lld} should
> affect -print-prog-name=ld output.
> 
>   # Should -fuse-ld= do anything with this?
>   % aarch64-linux-gnu-gcc -print-prog-name=../bin/ld
>   /usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/bin/../bin/ld

I think it would make sense, it allows to query the underlying static
linker used by the driver.  What does not make much sense to me is
allow arbitrary paths as input.

>  
> gcc/gcc.c has OPT_fuse_ld_bfd but not OPT_fuse_ld_lld, which may explain
> the behavior difference.

I think this is was oversight from lld gcc support and any case we need
to handle gcc that does not print the correct linker used if we want to
allow a way to set a non-default linker.

> 
> Clang does not have the GCC -fuse-ld= --print-prog-name=ld behavior.
> 
> 
> 
> 

This option is used solely to support --with-binutils.  Maybe we should
just remove it, since it is just simplify the use of a different binutils
and for clang it does not make sense (since it has different the integrated
assembly and different tool names).



>> Using ld.lld as the static linker name prints the expected result.
>>
>> This is only required when -fuse-ld=lld is used, if lld is used as
>> the 'ld' programs (through a symlink) LIBC_PROG_BINUTILS works
>> as expected.
>>
>> Checked on x86_64-linux-gnu.
>> ---
>> aclocal.m4 | 6 +++++-
>> configure  | 6 +++++-
>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/aclocal.m4 b/aclocal.m4
>> index c195c4db56..83da631822 100644
>> --- a/aclocal.m4
>> +++ b/aclocal.m4
>> @@ -114,8 +114,12 @@ if test -n "$path_binutils"; then
>>     path_binutils=`(cd $path_binutils; pwd) | sed 's%/*$%/%'`
>>     CC="$CC -B$path_binutils"
>> fi
>> +case "$CC" in
>> +    *fuse-ld=lld*) LDNAME=ld.lld;;
>> +    *)             LDNAME=ld;;
> 
> Perhaps hard code -fuse-ld=bfd and -fuse-ld=gold as well?
> 
> I think gcc -print-prog-name=ld.bfd is more robust than
> gcc -print-prog-name=ld -fuse-ld=bfd.

It outlines the missing gcc support, since with ld.bfd and ld.gold
does work with gcc.

I will maybe send a patch to remove LIBC_PROG_BINUTILS.

> 
>> +esac
>> AS=`$CC -print-prog-name=as`
>> -LD=`$CC -print-prog-name=ld`
>> +LD=`$CC -print-prog-name=$LDNAME`
>> AR=`$CC -print-prog-name=ar`
>> AC_SUBST(AR)
>> OBJDUMP=`$CC -print-prog-name=objdump`
>> diff --git a/configure b/configure
>> index 39d75eb4ed..2a28c58cd6 100755
>> --- a/configure
>> +++ b/configure
>> @@ -4549,8 +4549,12 @@ if test -n "$path_binutils"; then
>>     path_binutils=`(cd $path_binutils; pwd) | sed 's%/*$%/%'`
>>     CC="$CC -B$path_binutils"
>> fi
>> +case "$CC" in
>> +    *fuse-ld=lld*) LDNAME=ld.lld;;
>> +    *)             LDNAME=ld;;
>> +esac
>> AS=`$CC -print-prog-name=as`
>> -LD=`$CC -print-prog-name=ld`
>> +LD=`$CC -print-prog-name=$LDNAME`
>> AR=`$CC -print-prog-name=ar`
>>
>> OBJDUMP=`$CC -print-prog-name=objdump`
>> -- 
>> 2.32.0
>>