Re: forcing the linker to be a particular one (i.e. gold vs bfd)

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Matthias Klose]

On 10.10.2010 22:02, Kalle Olavi Niemitalo wrote:
> Basile Starynkevitch<basile@starynkevitch.net>  writes:
>
>> Of course, one can always force ld to be a particular linker (i.e. the
>> BFD one on a system where the default is GOLD, or vice versa) with ugly
>> $PATH and symlink tricks. But that is ugly.
>
> You mentioned you use Debian; their gcc-4.4 4.4.3-4 and later
> have a "gold-and-ld" patch to support gcc -fuse-ld=bfd and
> -fuse-ld=gold.  This patch is not in the FSF's GCC 4.4.5,
> 4.5.1, nor trunk.

sorry to say so, but that's a bad story.  this is a patch which is in current 
binutils trunk, submitted for review for gcc trunk,  finally got reviewed by 
Mark Mitchell after some months, but didn't get any feedback from the original 
submitter. With binutils 2.21 getting close to release, we'll have a mismatch 
with gcc and binutils.  any idea how to make some progress?

   Matthias

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 10/11/2010 12:17 AM, Matthias Klose wrote:
> On 10.10.2010 22:02, Kalle Olavi Niemitalo wrote:
>> Basile Starynkevitch<basile@starynkevitch.net> writes:
>>
>>> Of course, one can always force ld to be a particular linker (i.e. the
>>> BFD one on a system where the default is GOLD, or vice versa) with ugly
>>> $PATH and symlink tricks. But that is ugly.
>>
>> You mentioned you use Debian; their gcc-4.4 4.4.3-4 and later
>> have a "gold-and-ld" patch to support gcc -fuse-ld=bfd and
>> -fuse-ld=gold. This patch is not in the FSF's GCC 4.4.5,
>> 4.5.1, nor trunk.
>
> sorry to say so, but that's a bad story. this is a patch which is in
> current binutils trunk, submitted for review for gcc trunk, finally got
> reviewed by Mark Mitchell after some months, but didn't get any feedback
> from the original submitter. With binutils 2.21 getting close to
> release, we'll have a mismatch with gcc and binutils. any idea how to
> make some progress?
>
> Matthias
>
>
>

Hi Ian and Nick,

Nick, can you shed any light on your patch status?

TBD, here is the link on Debian's svn
http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512

1. Are you going to push it into gcc trunk/4.5.x/4.4.x?

2. Looks like the patch is a bit outdated, with binutils-2.21 release ld/gold
placement/naming is defined and IMO the line
+  static const char *const gold_suffix       = "gold";
should be
+  static const char *const gold_suffix       = "ld.gold";


Also I have several questions for both of you
(Further I suggest that gcc is being built against binutils-2.21):
3. What for do we need --enable-gold in configure.ac and
gcc_cv_gold/ORIGINAL_GOLD_FOR_TARGET,etc. in gcc/configure.ac, gcc/exec-tool.in?
For "Single tree build"?
Is this mode used widely? As I understand the most of people use separate
binutils/gcc build. In separate build default linker is specified
via binutils configure options. So we need not explicit gold support
in gcc's configure process.
Is "Single tree build" mode support important for gold developers?

4. Why did you convert -fuse-ld=gold/ld into -use-gold/-use-ld before
call collect2? I'd suggest to pass the option as is. In collect2 - extract
ld-name from the option, search for specified file(may be adding exe_suffix
if necessary) and launch the linker if found.

5. Ones we need to pass some options to collect2, what do you think
about -Wc,OPTIONS_FOR_COLLECT2 interface into gcc? Like
it is for -Wa/-Wl. "c" in -Wc means collect, may be -Wt is better
to avoid confusion with "C" as language.

Best regards
Vladimir Simonov

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Ian Lance Taylor]

Vladimir Simonov <sv@sw.ru> writes:

> 3. What for do we need --enable-gold in configure.ac and
> gcc_cv_gold/ORIGINAL_GOLD_FOR_TARGET,etc. in gcc/configure.ac, gcc/exec-tool.in?
> For "Single tree build"?
> Is this mode used widely? As I understand the most of people use separate
> binutils/gcc build. In separate build default linker is specified
> via binutils configure options. So we need not explicit gold support
> in gcc's configure process.
> Is "Single tree build" mode support important for gold developers?

Single tree build mode is not important for gold developers, at least
not for me.


> 5. Ones we need to pass some options to collect2, what do you think
> about -Wc,OPTIONS_FOR_COLLECT2 interface into gcc? Like
> it is for -Wa/-Wl. "c" in -Wc means collect, may be -Wt is better
> to avoid confusion with "C" as language.

I don't see a need for a special way to pass options to collect2.  -Wl
will pass options to collect2 just fine.  If there is some need, it
should not be -Wc, as libtool uses that to pass options to the compiler.


I don't personally care too much about this issue.  At Google we just
install GNU ld in a different directory under the name "ld", and pass a
-B option to gcc if we want to use it.  That approach doesn't require
any changes to any tools.  I'm not opposed to installing the linkers
under different names and coming up with some way to tell the compiler
which linker to use, I just don't personally care about it all that
much.

Ian

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 01/12/2011 06:16 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> 3. What for do we need --enable-gold in configure.ac and
>> gcc_cv_gold/ORIGINAL_GOLD_FOR_TARGET,etc. in gcc/configure.ac, gcc/exec-tool.in?
>> For "Single tree build"?
>> Is this mode used widely? As I understand the most of people use separate
>> binutils/gcc build. In separate build default linker is specified
>> via binutils configure options. So we need not explicit gold support
>> in gcc's configure process.
>> Is "Single tree build" mode support important for gold developers?
>
> Single tree build mode is not important for gold developers, at least
> not for me.
>
>
>> 5. Ones we need to pass some options to collect2, what do you think
>> about -Wc,OPTIONS_FOR_COLLECT2 interface into gcc? Like
>> it is for -Wa/-Wl. "c" in -Wc means collect, may be -Wt is better
>> to avoid confusion with "C" as language.
>
> I don't see a need for a special way to pass options to collect2.  -Wl
> will pass options to collect2 just fine.  If there is some need, it
> should not be -Wc, as libtool uses that to pass options to the compiler.
>
>
> I don't personally care too much about this issue.  At Google we just
> install GNU ld in a different directory under the name "ld", and pass a
> -B option to gcc if we want to use it.  That approach doesn't require
> any changes to any tools.  I'm not opposed to installing the linkers
> under different names and coming up with some way to tell the compiler
> which linker to use, I just don't personally care about it all that
> much.
>
> Ian
>
Thank you for replay.


So, trying to simplify Nick's patch we may:
1. Eliminate --enable-gold related changes in configure.ac,
gcc/configure.ac, gcc/exec-tool.in. I mean the patch, not
original files.

2. Taking into account current binutils installation layout, I see
two ways:
2.1 Add -Wl,--use-ld=LINKER_NAME support in collect2. collect2 will
strip --use-ld=LINKER_NAME from linker options and call appropriate
linker.
2.2 Leave gcc untouched and do the same work in binutils.
If --enable-gold specified in binutils configure options we create
simple wrapper which will strip --use-ld=LINKER_NAME from linker
options and call appropriate linker. Default linker is defined
by configure options. The wrapper is installed as ld.
The wrapper code should be located in gold directory and built
(and installed as ld) if "make" visits gold directory.

Both have pro and contra. 2.2 - decreases binutils install size,
leaves gcc untouched but adds additional "exec" during link process.

I can try to do any.
What do you think which is better?


Regards
Vladimir Simonov

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[H.J. Lu]

On Wed, Jan 12, 2011 at 9:22 AM, Vladimir Simonov <sv@sw.ru> wrote:
> On 01/12/2011 06:16 PM, Ian Lance Taylor wrote:
>>
>> Vladimir Simonov<sv@sw.ru>  writes:
>>
>>> 3. What for do we need --enable-gold in configure.ac and
>>> gcc_cv_gold/ORIGINAL_GOLD_FOR_TARGET,etc. in gcc/configure.ac,
>>> gcc/exec-tool.in?
>>> For "Single tree build"?
>>> Is this mode used widely? As I understand the most of people use separate
>>> binutils/gcc build. In separate build default linker is specified
>>> via binutils configure options. So we need not explicit gold support
>>> in gcc's configure process.
>>> Is "Single tree build" mode support important for gold developers?
>>
>> Single tree build mode is not important for gold developers, at least
>> not for me.
>>
>>
>>> 5. Ones we need to pass some options to collect2, what do you think
>>> about -Wc,OPTIONS_FOR_COLLECT2 interface into gcc? Like
>>> it is for -Wa/-Wl. "c" in -Wc means collect, may be -Wt is better
>>> to avoid confusion with "C" as language.
>>
>> I don't see a need for a special way to pass options to collect2.  -Wl
>> will pass options to collect2 just fine.  If there is some need, it
>> should not be -Wc, as libtool uses that to pass options to the compiler.
>>
>>
>> I don't personally care too much about this issue.  At Google we just
>> install GNU ld in a different directory under the name "ld", and pass a
>> -B option to gcc if we want to use it.  That approach doesn't require
>> any changes to any tools.  I'm not opposed to installing the linkers
>> under different names and coming up with some way to tell the compiler
>> which linker to use, I just don't personally care about it all that
>> much.
>>
>> Ian
>>
> Thank you for replay.
>
>
> So, trying to simplify Nick's patch we may:
> 1. Eliminate --enable-gold related changes in configure.ac,
> gcc/configure.ac, gcc/exec-tool.in. I mean the patch, not
> original files.
>
> 2. Taking into account current binutils installation layout, I see
> two ways:
> 2.1 Add -Wl,--use-ld=LINKER_NAME support in collect2. collect2 will
> strip --use-ld=LINKER_NAME from linker options and call appropriate
> linker.
> 2.2 Leave gcc untouched and do the same work in binutils.
> If --enable-gold specified in binutils configure options we create
> simple wrapper which will strip --use-ld=LINKER_NAME from linker
> options and call appropriate linker. Default linker is defined
> by configure options. The wrapper is installed as ld.
> The wrapper code should be located in gold directory and built
> (and installed as ld) if "make" visits gold directory.
>
> Both have pro and contra. 2.2 - decreases binutils install size,
> leaves gcc untouched but adds additional "exec" during link process.
>
> I can try to do any.
> What do you think which is better?
>

I don't think we should go with 2.2.  GCC driver already sets

COLLECT_GCC=/usr/gcc-4.6/bin/gcc
COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'

Why not add

COLLECT_LINKER=..............

which can be set by "gcc -flinker=ld.gold|ld.bfd"?

-- 
H.J.

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 01/12/2011 08:44 PM, H.J. Lu wrote:
> On Wed, Jan 12, 2011 at 9:22 AM, Vladimir Simonov<sv@sw.ru>  wrote:
>> 2.2 Leave gcc untouched and do the same work in binutils.
>> If --enable-gold specified in binutils configure options we create
>> simple wrapper which will strip --use-ld=LINKER_NAME from linker
>> options and call appropriate linker. Default linker is defined
>> by configure options. The wrapper is installed as ld.
>> The wrapper code should be located in gold directory and built
>> (and installed as ld) if "make" visits gold directory.
>>
>> Both have pro and contra. 2.2 - decreases binutils install size,
>> leaves gcc untouched but adds additional "exec" during link process.
>>
>> I can try to do any.
>> What do you think which is better?
>>
>
> I don't think we should go with 2.2.  GCC driver already sets
>
> COLLECT_GCC=/usr/gcc-4.6/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
> COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
>
> Why not add
>
> COLLECT_LINKER=..............
>
> which can be set by "gcc -flinker=ld.gold|ld.bfd"?
>

IMO duality in linker implementation should be hidden
from gcc as much as possible. Right now in plain gcc sources
we already have:
[gcc-4.5.2]$ grep -i -E "\<gold\>|_gold" * -r|wc -l
706

The more options we add to gcc the more problems
in gcc version switch(back and forward) appear for gcc users.

Anyway, consensus on this matter is desirable.

Regards
Vladimir Simonov

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[H.J. Lu]

On Wed, Jan 12, 2011 at 10:04 AM, Vladimir Simonov <sv@sw.ru> wrote:
> On 01/12/2011 08:44 PM, H.J. Lu wrote:
>>
>> On Wed, Jan 12, 2011 at 9:22 AM, Vladimir Simonov<sv@sw.ru>  wrote:
>>>
>>> 2.2 Leave gcc untouched and do the same work in binutils.
>>> If --enable-gold specified in binutils configure options we create
>>> simple wrapper which will strip --use-ld=LINKER_NAME from linker
>>> options and call appropriate linker. Default linker is defined
>>> by configure options. The wrapper is installed as ld.
>>> The wrapper code should be located in gold directory and built
>>> (and installed as ld) if "make" visits gold directory.
>>>
>>> Both have pro and contra. 2.2 - decreases binutils install size,
>>> leaves gcc untouched but adds additional "exec" during link process.
>>>
>>> I can try to do any.
>>> What do you think which is better?
>>>
>>
>> I don't think we should go with 2.2.  GCC driver already sets
>>
>> COLLECT_GCC=/usr/gcc-4.6/bin/gcc
>>
>> COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
>> COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=generic' '-march=x86-64'
>>
>> Why not add
>>
>> COLLECT_LINKER=..............
>>
>> which can be set by "gcc -flinker=ld.gold|ld.bfd"?
>>
>
> IMO duality in linker implementation should be hidden
> from gcc as much as possible. Right now in plain gcc sources
> we already have:
> [gcc-4.5.2]$ grep -i -E "\<gold\>|_gold" * -r|wc -l
> 706
>
> The more options we add to gcc the more problems
> in gcc version switch(back and forward) appear for gcc users.
>

If you want to hide it from gcc driver, then you should do what
Ian suggested to use -B.

-- 
H.J.

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Matthias Klose]

On 12.01.2011 19:39, H.J. Lu wrote:
>> The more options we add to gcc the more problems
>> in gcc version switch(back and forward) appear for gcc users.
>>
>
> If you want to hide it from gcc driver, then you should do what
> Ian suggested to use -B.

-B is acceptable for somebody who knows where an alternative ld is installed. 
It's horrible for anybody else who needs to figure out the location where an 
alternative ld is installed. This includes upstreams and distribution makers.

I had the linker patch updated the last time in Nov/Dec. I'll try to update it 
this week.

   Matthias

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[H.J. Lu]

On Wed, Jan 12, 2011 at 12:21 PM, Matthias Klose <doko@ubuntu.com> wrote:
> On 12.01.2011 19:39, H.J. Lu wrote:
>>>
>>> The more options we add to gcc the more problems
>>> in gcc version switch(back and forward) appear for gcc users.
>>>
>>
>> If you want to hide it from gcc driver, then you should do what
>> Ian suggested to use -B.
>
> -B is acceptable for somebody who knows where an alternative ld is
> installed. It's horrible for anybody else who needs to figure out the
> location where an alternative ld is installed. This includes upstreams and
> distribution makers.
>

That is why I suggested something like "gcc -flinker=ld.bfd|ld.gold"

-- 
H.J.

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 01/12/2011 11:32 PM, H.J. Lu wrote:
> On Wed, Jan 12, 2011 at 12:21 PM, Matthias Klose<doko@ubuntu.com>  wrote:
>> On 12.01.2011 19:39, H.J. Lu wrote:
>>>>
>>>> The more options we add to gcc the more problems
>>>> in gcc version switch(back and forward) appear for gcc users.
>>>>
>>>
>>> If you want to hide it from gcc driver, then you should do what
>>> Ian suggested to use -B.
>>
>> -B is acceptable for somebody who knows where an alternative ld is
>> installed. It's horrible for anybody else who needs to figure out the
>> location where an alternative ld is installed. This includes upstreams and
>> distribution makers.
>>
>
> That is why I suggested something like "gcc -flinker=ld.bfd|ld.gold"
>
Hi all,

H.J., you suggest the same what was already done.
In Nick's gcc patch. Except gcc option name.

See link in my original e-mail.
http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512

So. We have:
1. "-B" solution is unacceptable for package-based distributions.
In this case binutils-gold package must be introduced.
With different install-root. And so on...
2. Nick's patch implementing linker switch in gcc.
The patch may be slightly emended and pushed into gcc.
3. Matthias promises to implement the switch into
binutils. This patch may be pushed into binutils.

Am I correct?

IMO gcc/binutils maintainers opinion is important
here. What is the right place to do linker switch?

Ian?
Others?

Thank you
Vladimir Simonov

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[H.J. Lu]

On Wed, Jan 12, 2011 at 11:06 PM, Vladimir Simonov <sv@sw.ru> wrote:
> On 01/12/2011 11:32 PM, H.J. Lu wrote:
>>
>> On Wed, Jan 12, 2011 at 12:21 PM, Matthias Klose<doko@ubuntu.com>  wrote:
>>>
>>> On 12.01.2011 19:39, H.J. Lu wrote:
>>>>>
>>>>> The more options we add to gcc the more problems
>>>>> in gcc version switch(back and forward) appear for gcc users.
>>>>>
>>>>
>>>> If you want to hide it from gcc driver, then you should do what
>>>> Ian suggested to use -B.
>>>
>>> -B is acceptable for somebody who knows where an alternative ld is
>>> installed. It's horrible for anybody else who needs to figure out the
>>> location where an alternative ld is installed. This includes upstreams
>>> and
>>> distribution makers.
>>>
>>
>> That is why I suggested something like "gcc -flinker=ld.bfd|ld.gold"
>>
> Hi all,
>
> H.J., you suggest the same what was already done.
> In Nick's gcc patch. Except gcc option name.
>
> See link in my original e-mail.
> http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512
>
> So. We have:
> 1. "-B" solution is unacceptable for package-based distributions.
> In this case binutils-gold package must be introduced.
> With different install-root. And so on...
> 2. Nick's patch implementing linker switch in gcc.
> The patch may be slightly emended and pushed into gcc.
> 3. Matthias promises to implement the switch into
> binutils. This patch may be pushed into binutils.
>
> Am I correct?
>
> IMO gcc/binutils maintainers opinion is important
> here. What is the right place to do linker switch?
>

Not in binutils.

-- 
H.J.

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Ian Lance Taylor]

Vladimir Simonov <sv@sw.ru> writes:

> See link in my original e-mail.
> http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512
>
> So. We have:
> 1. "-B" solution is unacceptable for package-based distributions.
> In this case binutils-gold package must be introduced.
> With different install-root. And so on...
> 2. Nick's patch implementing linker switch in gcc.
> The patch may be slightly emended and pushed into gcc.
> 3. Matthias promises to implement the switch into
> binutils. This patch may be pushed into binutils.
>
> Am I correct?
>
> IMO gcc/binutils maintainers opinion is important
> here. What is the right place to do linker switch?
>
> Ian?
> Others?

It seems to clear to me that any choice of linker must be made in gcc,
either in the gcc driver proper or in collect2.

I'm sorry I'm not up on the status of this.  Is there a patch awaiting
review?

Ian

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 01/13/2011 08:33 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> See link in my original e-mail.
>> http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512
>>
>> So. We have:
>> 1. "-B" solution is unacceptable for package-based distributions.
>> In this case binutils-gold package must be introduced.
>> With different install-root. And so on...
>> 2. Nick's patch implementing linker switch in gcc.
>> The patch may be slightly emended and pushed into gcc.
>> 3. Matthias promises to implement the switch into
>> binutils. This patch may be pushed into binutils.
>>
>> Am I correct?
>>
>> IMO gcc/binutils maintainers opinion is important
>> here. What is the right place to do linker switch?
>>
>> Ian?
>> Others?
>
> It seems to clear to me that any choice of linker must be made in gcc,
> either in the gcc driver proper or in collect2.
>
> I'm sorry I'm not up on the status of this.  Is there a patch awaiting
> review?
>
> Ian
>

Patch from Nick Clifton against gcc 4.4.x is here
http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512

I don't see Nick's comments so I suggest to discuss the patch.
Later it may be fixed according discussion results, adopted for
gcc trunk and put onto review by Nick, may be me, may be somebody
else.

I have the following points:
1. Looks like the patch is a bit outdated, with binutils-2.21 release ld/gold
placement/naming is defined and IMO the line
+  static const char *const gold_suffix       = "gold";
should be
+  static const char *const gold_suffix       = "ld.gold";

2. Ones you are not interested in "Single tree build" mode
support, the changes related to --enable-gold in configure.ac,
gcc/configure.ac, gcc/exec-tool.in may be dropped. They increase
the patch. After regeneration configures full patch becomes
about 25Kb.

3. It looks unclear for me what for conversion -fuse-ld=gold/ld into
-use-gold/-use-ld before call collect2 is used. I'd suggest to pass the
option to collect2 as is. In collect2 - extract
ld-name from the option, and use option's value as part of linker's name
for further search. This point is not too important for me.

OK?
Your opinion?

Regards
Vladimir

PS Could you briefly explain why changes in gcc/collect2 are better than
ones in binutils?
I've mentioned pro and contras - switch in binutils decreases binutils
install size, leaves gcc untouched but adds additional "exec" during link
process. Additional "exec" outweighs?

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Ian Lance Taylor]

Vladimir Simonov <sv@sw.ru> writes:

> Patch from Nick Clifton against gcc 4.4.x is here
> http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512

I didn't look at it in detail, but that patch looks more or less fine to
me.  Nick, have you sent it to gcc-patches?  Do you want to?

> PS Could you briefly explain why changes in gcc/collect2 are better than
> ones in binutils?
> I've mentioned pro and contras - switch in binutils decreases binutils
> install size, leaves gcc untouched but adds additional "exec" during link
> process. Additional "exec" outweighs?

The gcc driver and collect2 are already set up to pick which linker to
execute, and it's relatively easy to direct them to pick a different
one.  To me it makes sense to just take advantage of that fact.

Ian

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[H.J. Lu]

On Thu, Jan 13, 2011 at 11:42 AM, Ian Lance Taylor <iant@google.com> wrote:
> Vladimir Simonov <sv@sw.ru> writes:
>
>> Patch from Nick Clifton against gcc 4.4.x is here
>> http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512
>
> I didn't look at it in detail, but that patch looks more or less fine to
> me.  Nick, have you sent it to gcc-patches?  Do you want to?
>
>> PS Could you briefly explain why changes in gcc/collect2 are better than
>> ones in binutils?
>> I've mentioned pro and contras - switch in binutils decreases binutils
>> install size, leaves gcc untouched but adds additional "exec" during link
>> process. Additional "exec" outweighs?
>
> The gcc driver and collect2 are already set up to pick which linker to
> execute, and it's relatively easy to direct them to pick a different
> one.  To me it makes sense to just take advantage of that fact.
>

I added --with-plugin-ld so that we can pick a different linker for
plugin at configure time since at that time GNU linker didn't support
plugin.  We should kill --with-plugin-ld and make it a run-time option
to select a linker for plugin and non-plugin.


-- 
H.J.

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 01/13/2011 10:42 PM, Ian Lance Taylor wrote:
> Vladimir Simonov<sv@sw.ru>  writes:
>
>> Patch from Nick Clifton against gcc 4.4.x is here
>> http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512
>
> I didn't look at it in detail, but that patch looks more or less fine to
> me.  Nick, have you sent it to gcc-patches?  Do you want to?
>

Looks like Nick is not in the list at the moment.
Let's wait him.

May I rely on new gcc option name?
I mean that -fuse-ld={ld,gold} won't be changed.

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Ian Lance Taylor]

Vladimir Simonov <sv@sw.ru> writes:

> May I rely on new gcc option name?
> I mean that -fuse-ld={ld,gold} won't be changed.

I don't see why it would be changed, but I wouldn't want to tell you to
*rely* on it before the patch has been approved.

Ian

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Nick Clifton]

Hi Vladimir,

   I am sorry but I am out of touch with this topic.  It seems to me 
that there are two solutions:

  1. Use gcc's -B command line switch to select a directory containing 
the desired linker, or more probably the desired collect2 or exec-tool 
script.

  2. Add a new GCC command line switch to allow the user to select a 
linker by name and then provide a mechanism for locating it.

Option 1 is easy and requires no changes, but as Matthias already 
pointed out, it only works if the user (or build mechanism) already 
knows where the linker(s) have been installed.

If I remember correctly my original patch implemented option 2 by adding 
some more logic to gcc/exec-tool.in.  I still think that this is the 
easiest solution.  It should mean no other changes to gcc or the 
binutils and it makes use of a linker wrapper mechanism that is already 
in place.

Cheers
   Nick

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Vladimir Simonov]

On 01/19/2011 09:06 PM, Nick Clifton wrote:
> Hi Vladimir,
>
...

> If I remember correctly my original patch implemented option 2 by adding
> some more logic to gcc/exec-tool.in. I still think that this is the
> easiest solution. It should mean no other changes to gcc or the binutils
> and it makes use of a linker wrapper mechanism that is already in place.
>
> Cheers
> Nick
>

Hi Nick,

The thread a bit long, may be because my questions also:)
Looks like you've lost the question about your patch.
See below

Regards
Vladimir

On Thu, Jan 13, 2011 at 11:42 AM, Ian Lance Taylor <iant@google.com> wrote:
 > > Vladimir Simonov <sv@sw.ru> writes:
 > >
 >> >> Patch from Nick Clifton against gcc 4.4.x is here
 >> >> 
http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc-4.4/debian/patches/gold-and-ld.diff?view=log&pathrev=4512
 > >
 > > I didn't look at it in detail, but that patch looks more or less fine to
 > > me.  Nick, have you sent it to gcc-patches?  Do you want to?
 > >

Re: forcing the linker to be a particular one (i.e. gold vs bfd)

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

On 19.01.2011 19:06, Nick Clifton wrote:
> Hi Vladimir,
>
> I am sorry but I am out of touch with this topic. It seems to me that there are
> two solutions:
>
> 1. Use gcc's -B command line switch to select a directory containing the desired
> linker, or more probably the desired collect2 or exec-tool script.
>
> 2. Add a new GCC command line switch to allow the user to select a linker by
> name and then provide a mechanism for locating it.
>
> Option 1 is easy and requires no changes, but as Matthias already pointed out,
> it only works if the user (or build mechanism) already knows where the linker(s)
> have been installed.
>
> If I remember correctly my original patch implemented option 2 by adding some
> more logic to gcc/exec-tool.in. I still think that this is the easiest solution.
> It should mean no other changes to gcc or the binutils and it makes use of a
> linker wrapper mechanism that is already in place.

here is the patch originally written by Nick, and updated to the current trunk; 
lto test cases still don't work.  I think I'm getting the linker selection wrong 
for these cases.

   Matthias

[-- Attachment #2: gold-and-ld.diff --]
[-- Type: text/plain, Size: 16604 bytes --]

Index: gcc/doc/invoke.texi
===================================================================
--- gcc/doc/invoke.texi	(revision 168860)
+++ gcc/doc/invoke.texi	(working copy)
@@ -399,7 +399,7 @@
 -funit-at-a-time -funroll-all-loops -funroll-loops @gol
 -funsafe-loop-optimizations -funsafe-math-optimizations -funswitch-loops @gol
 -fvariable-expansion-in-unroller -fvect-cost-model -fvpt -fweb @gol
--fwhole-program -fwpa -fuse-linker-plugin @gol
+-fwhole-program -fwpa -fuse-ld -fuse-linker-plugin @gol
 --param @var{name}=@var{value}
 -O  -O0  -O1  -O2  -O3  -Os -Ofast}
 
@@ -7689,6 +7689,16 @@
 Enabled by default when LTO support in GCC is enabled and GCC was compiled
 with linker supporting plugins (GNU ld or @code{gold}).
 
+@item -fuse-ld=gold
+Use the @command{gold} linker instead of the default linker.
+This option is only necessary if GCC has been configured with
+@option{--enable-gold} and @option{--enable-ld=default}.
+
+@item -fuse-ld=bfd
+Use the @command{ld.bfd} linker instead of the default linker.
+This option is only necessary if GCC has been configured with
+@option{--enable-gold} and @option{--enable-ld}.
+
 @item -fcprop-registers
 @opindex fcprop-registers
 After register allocation and post-register allocation instruction splitting,
Index: gcc/gcc.c
===================================================================
--- gcc/gcc.c	(revision 168860)
+++ gcc/gcc.c	(working copy)
@@ -656,6 +656,9 @@
     }"PLUGIN_COND_CLOSE" \
     %{flto|flto=*:%<fcompare-debug*} \
     %{flto} %{flto=*} %l " LINK_PIE_SPEC \
+   "%{fuse-ld=gold:%{fuse-ld=bfd:%e-fuse-ld=gold and -fuse-ld=bfd may not be used together}} \
+    %{fuse-ld=gold:-use-gold} \
+    %{fuse-ld=bfd:-use-ld}" \
    "%X %{o*} %{e*} %{N} %{n} %{r}\
     %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}}\
     %{static:} %{L*} %(mfwrap) %(link_libgcc) %o\
Index: gcc/opts.c
===================================================================
--- gcc/opts.c	(revision 168860)
+++ gcc/opts.c	(working copy)
@@ -1691,8 +1691,9 @@
       dc->max_errors = value;
       break;
 
+    case OPT_fuse_ld_:
     case OPT_fuse_linker_plugin:
-      /* No-op. Used by the driver and passed to us because it starts with f.*/
+      /* No-op. Used by the driver and passed to us because it starts with f.  */
       break;
 
     default:
Index: gcc/configure.ac
===================================================================
--- gcc/configure.ac	(revision 168860)
+++ gcc/configure.ac	(working copy)
@@ -1937,6 +1937,17 @@
         AC_PATH_PROG(gcc_cv_ld, $LD_FOR_TARGET)
 fi])
 
+gcc_cv_ld_gold_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/gold
+
+AS_VAR_SET_IF(gcc_cv_gold,, [
+if test -f $gcc_cv_ld_gold_srcdir/configure.ac \
+     && test -f ../gold/Makefile \
+     && test x$build = x$host; then
+	gcc_cv_gold=../gold/ld-new$build_exeext
+else
+        gcc_cv_gold=''
+fi])
+
 ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
 PLUGIN_LD=`basename $gcc_cv_ld`
 AC_ARG_WITH(plugin-ld,
@@ -1966,6 +1977,9 @@
   *) AC_CONFIG_FILES(collect-ld:exec-tool.in, [chmod +x collect-ld]) ;;
 esac 
 
+ORIGINAL_GOLD_FOR_TARGET=$gcc_cv_gold
+AC_SUBST(ORIGINAL_GOLD_FOR_TARGET)
+
 AC_MSG_CHECKING(what linker to use)
 if test "$gcc_cv_ld" = ../ld/ld-new$build_exeext; then
 	# Single tree build which includes ld.  We want to prefer it
Index: gcc/exec-tool.in
===================================================================
--- gcc/exec-tool.in	(revision 168860)
+++ gcc/exec-tool.in	(working copy)
@@ -1,6 +1,6 @@
 #! /bin/sh
 
-# Copyright (C) 2007, 2008, 2010 Free Software Foundation, Inc.
+# Copyright (C) 2007, 2008, 2010, 2011 Free Software Foundation, Inc.
 # This file is part of GCC.
 
 # GCC is free software; you can redistribute it and/or modify
@@ -21,11 +21,13 @@
 
 ORIGINAL_AS_FOR_TARGET="@ORIGINAL_AS_FOR_TARGET@"
 ORIGINAL_LD_FOR_TARGET="@ORIGINAL_LD_FOR_TARGET@"
+ORIGINAL_GOLD_FOR_TARGET="@ORIGINAL_GOLD_FOR_TARGET@"
 ORIGINAL_PLUGIN_LD_FOR_TARGET="@ORIGINAL_PLUGIN_LD_FOR_TARGET@"
 ORIGINAL_NM_FOR_TARGET="@ORIGINAL_NM_FOR_TARGET@"
 exeext=@host_exeext@
 fast_install=@enable_fast_install@
 objdir=@objdir@
+version="1.1"
 
 invoked=`basename "$0"`
 id=$invoked
@@ -36,15 +38,44 @@
     dir=gas
     ;;
   collect-ld)
-    # when using a linker plugin, gcc will always pass '-plugin' as the
-    # first or second option to the linker.
-    if test x"$1" = "x-plugin" || test x"$2" = "x-plugin"; then
-      original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
-    else
-      original=$ORIGINAL_LD_FOR_TARGET
+    prog=ld-new$exeext
+    # Look for the a command line option
+    # specifying the linker to be used.
+    case " $* " in
+      *\ -use-gold\ *)
+        original=$ORIGINAL_GOLD_FOR_TARGET
+	dir=gold
+        ;;
+      *\ -use-ld\ * | *\ -use-ld.bfd\ *)
+        original=$ORIGINAL_LD_FOR_TARGET
+        dir=ld
+        ;;
+      *\ -plugin\ *)
+        original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
+        dir=ld
+	;;
+      *)
+        original=$ORIGINAL_LD_FOR_TARGET
+        dir=ld
+	;;
+    esac
+
+    # If the selected linker has not been configured then
+    # try using the others, in the order PLUGIN-LD, LD, GOLD.
+    if test x"$original" = x; then
+      if test x"$ORIGINAL_PLUGIN_LD_FOR_TARGET" != x; then
+        original=$ORIGINAL_PLUGIN_LD_FOR_TARGET
+        dir=ld
+      elif test x"$ORIGINAL_LD_FOR_TARGET" != x; then
+        original=$ORIGINAL_LD_FOR_TARGET
+        dir=ld
+      elif test x"$ORIGINAL_GOLD_FOR_TARGET" != x; then
+        original=$ORIGINAL_GOLD_FOR_TARGET
+        dir=gold
+      # Otherwise do nothing - the case statement below
+      # will issue an error message for us.
+      fi
     fi
-    prog=ld-new$exeext
-    dir=ld
     id=ld
     ;;
   nm)
@@ -61,29 +92,58 @@
     scriptdir=`cd "$tdir" && pwd`
 
     if test -x $scriptdir/../$dir/$prog; then
-      test "$fast_install" = yes || exec $scriptdir/../$dir/$prog ${1+"$@"}
+      if test "$fast_install" = yes; then
+        # If libtool did everything it needs to do, there's a fast path.
+        lt_prog=$scriptdir/../$dir/$objdir/lt-$prog 
 
-      # if libtool did everything it needs to do, there's a fast path
-      lt_prog=$scriptdir/../$dir/$objdir/lt-$prog 
-      test -x $lt_prog && exec $lt_prog ${1+"$@"}
-
-      # libtool has not relinked ld-new yet, but we cannot just use the
-      # previous stage (because then the relinking would just never happen!).
-      # So we take extra care to use prev-ld/ld-new *on recursive calls*.
-      eval LT_RCU="\${LT_RCU_$id}"
-      test x"$LT_RCU" = x"1" && exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
-
-      eval LT_RCU_$id=1
-      export LT_RCU_$id
-      $scriptdir/../$dir/$prog ${1+"$@"}
-      result=$?
-      exit $result
-
+	if test -x $lt_prog; then
+	  original=$lt_prog
+        else
+          # Libtool has not relinked ld-new yet, but we cannot just use the
+          # previous stage (because then the relinking would just never happen!).
+          # So we take extra care to use prev-ld/ld-new *on recursive calls*.
+          eval LT_RCU="\${LT_RCU_$id}"
+          if test x"$LT_RCU" = x"1"; then
+	    original=$scriptdir/../prev-$dir/$prog
+          else
+            eval LT_RCU_$id=1
+            export LT_RCU_$id
+            case " $* " in
+              *\ -v\ *)
+               echo "$invoked $version"
+               echo $scriptdir/../$dir/$prog $*
+               ;;
+            esac
+            $scriptdir/../$dir/$prog ${1+"$@"}
+            result=$?
+            exit $result
+          fi
+        fi
+      else
+	original=$scriptdir/../$dir/$prog
+      fi
     else
-      exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
+      original=$scriptdir/../prev-$dir/$prog
     fi
     ;;
-  *)
-    exec $original ${1+"$@"}
+  "")
+    echo "$invoked: executable not configured"
+    exit 1
     ;;
 esac
+
+# If -v has been used then display our version number
+# and then echo the command we are about to invoke.
+case " $* " in
+  *\ -v\ *)
+    echo "$invoked $version"
+    echo $original $*
+    ;;
+esac
+
+if test -x $original; then
+  exec "$original" ${1+"$@"}
+else
+  echo "$invoked: unable to locate executable: $original"
+  exit 1
+fi
Index: gcc/common.opt
===================================================================
--- gcc/common.opt	(revision 168860)
+++ gcc/common.opt	(working copy)
@@ -1998,6 +1998,9 @@
 Common Report Var(flag_unwind_tables) Optimization
 Just generate unwind tables for exception handling
 
+fuse-ld=
+Common Joined Undocumented
+
 fuse-linker-plugin
 Common Undocumented
 
Index: gcc/collect2.c
===================================================================
--- gcc/collect2.c	(revision 168860)
+++ gcc/collect2.c	(working copy)
@@ -1075,17 +1075,19 @@
 int
 main (int argc, char **argv)
 {
-  static const char *const ld_suffix	= "ld";
-  static const char *const plugin_ld_suffix = PLUGIN_LD;
-  static const char *const real_ld_suffix = "real-ld";
+  static const char *const ld_suffix	     = "ld";
+  static const char *const gold_suffix       = "gold";
+  static const char *const bfd_ld_suffix     = "ld.bfd";
+  static const char *const plugin_ld_suffix  = PLUGIN_LD;
+  static const char *const real_ld_suffix    = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
-  static const char *const nm_suffix	= "nm";
-  static const char *const gnm_suffix	= "gnm";
+  static const char *const nm_suffix	     = "nm";
+  static const char *const gnm_suffix	     = "gnm";
 #ifdef LDD_SUFFIX
-  static const char *const ldd_suffix	= LDD_SUFFIX;
+  static const char *const ldd_suffix	     = LDD_SUFFIX;
 #endif
-  static const char *const strip_suffix = "strip";
-  static const char *const gstrip_suffix = "gstrip";
+  static const char *const strip_suffix      = "strip";
+  static const char *const gstrip_suffix     = "gstrip";
 
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
@@ -1095,6 +1097,10 @@
 
   const char *const full_ld_suffix =
     concat(target_machine, "-", ld_suffix, NULL);
+  const char *const full_gold_suffix =
+    concat (target_machine, "-", gold_suffix, NULL);
+  const char *const full_bfd_ld_suffix =
+    concat (target_machine, "-", bfd_ld_suffix, NULL);
   const char *const full_plugin_ld_suffix =
     concat(target_machine, "-", plugin_ld_suffix, NULL);
   const char *const full_nm_suffix =
@@ -1110,15 +1116,17 @@
   const char *const full_gstrip_suffix =
     concat (target_machine, "-", gstrip_suffix, NULL);
 #else
-  const char *const full_ld_suffix	= ld_suffix;
+  const char *const full_ld_suffix	  = ld_suffix;
+  const char *const full_gold_suffix	  = gold_suffix;
+  const char *const full_bfd_ld_suffix	  = bfd_ld_suffix;
   const char *const full_plugin_ld_suffix = plugin_ld_suffix;
-  const char *const full_nm_suffix	= nm_suffix;
-  const char *const full_gnm_suffix	= gnm_suffix;
+  const char *const full_nm_suffix	  = nm_suffix;
+  const char *const full_gnm_suffix	  = gnm_suffix;
 #ifdef LDD_SUFFIX
-  const char *const full_ldd_suffix	= ldd_suffix;
+  const char *const full_ldd_suffix	  = ldd_suffix;
 #endif
-  const char *const full_strip_suffix	= strip_suffix;
-  const char *const full_gstrip_suffix	= gstrip_suffix;
+  const char *const full_strip_suffix	  = strip_suffix;
+  const char *const full_gstrip_suffix	  = gstrip_suffix;
 #endif /* CROSS_DIRECTORY_STRUCTURE */
 
   const char *arg;
@@ -1132,7 +1140,13 @@
   const char **c_ptr;
   char **ld1_argv;
   const char **ld1;
-  bool use_plugin = false;
+  enum linker_select
+  {
+    DFLT_LINKER,
+    PLUGIN_LINKER,
+    GOLD_LINKER,
+    BFD_LINKER
+  } selected_linker = DFLT_LINKER;
 
   /* The kinds of symbols we will have to consider when scanning the
      outcome of a first pass link.  This is ALL to start with, then might
@@ -1209,15 +1223,21 @@
         else if (! strcmp (argv[i], "-flto-partition=none"))
 	  no_partition = true;
         else if ((! strncmp (argv[i], "-flto=", 6)
-		  || ! strcmp (argv[i], "-flto")) && ! use_plugin)
+		  || ! strcmp (argv[i], "-flto"))
+		 && selected_linker != PLUGIN_LINKER)
 	  lto_mode = LTO_MODE_WHOPR;
 	else if (!strncmp (argv[i], "-fno-lto", 8))
 	  lto_mode = LTO_MODE_NONE;
         else if (! strcmp (argv[i], "-plugin"))
 	  {
-	    use_plugin = true;
+	    selected_linker =  PLUGIN_LINKER;
 	    lto_mode = LTO_MODE_NONE;
 	  }
+	else if (! strcmp (argv[i], "-use-gold"))
+	  selected_linker = GOLD_LINKER;
+	else if (! strcmp (argv[i], "-use-ld"))
+	  selected_linker = BFD_LINKER;
+
 #ifdef COLLECT_EXPORT_LIST
 	/* since -brtl, -bexport, -b64 are not position dependent
 	   also check for them here */
@@ -1299,36 +1319,109 @@
   /* Try to discover a valid linker/nm/strip to use.  */
 
   /* Maybe we know the right file to use (if not cross).  */
-  ld_file_name = 0;
+  ld_file_name = NULL;
 #ifdef DEFAULT_LINKER
   if (access (DEFAULT_LINKER, X_OK) == 0)
     ld_file_name = DEFAULT_LINKER;
-  if (ld_file_name == 0)
+  if (ld_file_name == NULL)
 #endif
 #ifdef REAL_LD_FILE_NAME
   ld_file_name = find_a_file (&path, REAL_LD_FILE_NAME);
-  if (ld_file_name == 0)
+  if (ld_file_name == NULL)
 #endif
   /* Search the (target-specific) compiler dirs for ld'.  */
   ld_file_name = find_a_file (&cpath, real_ld_suffix);
   /* Likewise for `collect-ld'.  */
-  if (ld_file_name == 0)
+  if (ld_file_name == NULL)
     ld_file_name = find_a_file (&cpath, collect_ld_suffix);
   /* Search the compiler directories for `ld'.  We have protection against
      recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-    ld_file_name = find_a_file (&cpath,
-				use_plugin
-				? plugin_ld_suffix
-				: ld_suffix);
+  if (ld_file_name == NULL)
+    switch (selected_linker)
+      {
+      default:
+      case DFLT_LINKER:
+	ld_file_name = find_a_file (&cpath, ld_suffix);
+	break;
+      case PLUGIN_LINKER:
+	ld_file_name = find_a_file (&cpath, plugin_ld_suffix);
+	break;
+      case GOLD_LINKER:
+	ld_file_name = find_a_file (&cpath, gold_suffix);
+	break;
+      case BFD_LINKER:
+	ld_file_name = find_a_file (&cpath, bfd_ld_suffix);
+	break;
+      }
   /* Search the ordinary system bin directories
      for `ld' (if native linking) or `TARGET-ld' (if cross).  */
-  if (ld_file_name == 0)
-    ld_file_name = find_a_file (&path,
-				use_plugin
-				? full_plugin_ld_suffix
-				: full_ld_suffix);
+  if (ld_file_name == NULL)
+    switch (selected_linker)
+      {
+      default:
+      case DFLT_LINKER:
+	ld_file_name = find_a_file (&path, full_ld_suffix);
+	break;
+      case PLUGIN_LINKER:
+	ld_file_name = find_a_file (&path, full_plugin_ld_suffix);
+	break;
+      case GOLD_LINKER:
+	ld_file_name = find_a_file (&path, full_gold_suffix);
+	break;
+      case BFD_LINKER:
+	ld_file_name = find_a_file (&path, full_bfd_ld_suffix);
+	break;
+      }
+  /* If we failed to find a plugin-capable linker, try the ordinary one.  */
+  if (ld_file_name == NULL && selected_linker == PLUGIN_LINKER)
+    ld_file_name = find_a_file (&cpath, ld_suffix);
 
+  if ((vflag || debug) && ld_file_name == NULL)
+    {
+      struct prefix_list * p;
+      const char * s;
+
+      notice ("collect2: warning: unable to find linker.\n");
+
+#ifdef DEFAULT_LINKER
+      notice (" Searched for this absolute executable:\n");
+      notice (" %s\n", DEFAULT_LINKER);
+#endif
+
+      notice (" Searched in these paths:\n");
+      for (p = cpath.plist; p != NULL; p = p->next)
+	notice ("  %s\n", p->prefix);
+      notice (" For these executables:\n");
+      notice ("  %s\n", real_ld_suffix);
+      notice ("  %s\n", collect_ld_suffix);
+      switch (selected_linker)
+      {
+      default:
+      case DFLT_LINKER:    s = ld_suffix; break;
+      case PLUGIN_LINKER:  s = plugin_ld_suffix; break;
+      case GOLD_LINKER:    s = gold_suffix; break;
+      case BFD_LINKER:     s = bfd_ld_suffix; break;
+      }
+      notice ("  %s\n", s);
+
+      notice (" And searched in these paths:\n");
+      for (p = path.plist; p != NULL; p = p->next)
+	notice ("  %s\n", p->prefix);
+      notice (" For these executables:\n");
+#ifdef REAL_LD_FILE_NAME
+      notice (" %s\n", REAL_LD_FILE_NAME);
+#endif
+      switch (selected_linker)
+      {
+      default:
+      case DFLT_LINKER:    s = full_ld_suffix; break;
+      case PLUGIN_LINKER:  s = full_plugin_ld_suffix; break;
+      case GOLD_LINKER:    s = full_gold_suffix; break;
+      case BFD_LINKER:     s = full_bfd_ld_suffix; break;
+      }
+      notice ("  %s\n", s);
+    }
+
 #ifdef REAL_NM_FILE_NAME
   nm_file_name = find_a_file (&path, REAL_NM_FILE_NAME);
   if (nm_file_name == 0)