[cfe-dev] [RFC] Recognize -fuse-ld={bfd, gold, lld} but don't prepend "ld." or "ld64." for other values

[Fangrui Song via cfe-dev]

On 2020-06-03, David Chisnall via cfe-dev wrote:
>On 02/06/2020 19:47, Fangrui Song via cfe-dev wrote:
>>If they use a relative path, they can't be benefiting from ld. prefix
>
>This depends on how they specify the path.  If they specify a path for 
>the linker via -fuse-ld, they don't get the prefix.  Most 
>cross-compile toolchains that I've seen don't do that.  Instead, they 
>use -B to specify a path to find *all* of the tools and then use 
>-fuse-ld={lld,gold,bfd,proprietary linker's name}.
>
>That is the use case I'm concerned about breaking.  The behaviour of 
>-B is to prepend a search path, but still fall back to the default 
>paths if a tool is not found there.  For example, if I have:
>
>/usr/bin/lld
>/my/custom/sdk/bin/ld.lld
>
>If I run:
>
>$ clang -B /my/custom/sdk/bin/ -fuse-ld=lld ...
>
>Today, I will run my cross-compile toolchain's linker.  With your 
>proposed change, I will run my system LLD install.  As a user, I will 
>see very confusing error messages from the system linker if it can't 
>handle my cross-compile target.  Worse, I may see a binary linked with 
>a linker that defaults to a different linker script, but still 
>produces some output.
>
>David

-fuse-ld={bfd,gold,lld} is compatible with the previous behavior.

Do you propose that:

* -fuse-ld={bfd,gold.lld} should find "ld.{bfd,gold,lld}" in COMPILER_PATH
* all -fuse-ld=word should find "word" in COMPILER_PATH
* -fuse-ld=relative/path should find "relative/path" in PATH?