[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, James Y Knight wrote:
>On Tue, Jun 2, 2020 at 2:19 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Mon, Jun 1, 2020 at 9:47 PM James Y Knight via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> >
>> >
>> >
>> > On Wed, May 20, 2020 at 3:10 PM Fangrui Song via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>> >>
>> >> In https://reviews.llvm.org/D80225 I intended to update the semantics
>> of -fuse-ld=
>> >> Some context (from my archaeology) about the option
>> >>
>> >> * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470 added support for
>> -fuse-ld=bfd to mean ld.bfd and -fuse-ld=gold to mean ld.gold
>> >> * rL194328 ported the feature and made -fuse-ld= available for other
>> values (with the ld. prefix)
>> >> * D78290 changed the prefix to ld64. on Darwin.
>> >> * GCC added support for -fuse-ld=lld. No other value than bfd,gold,lld
>> is allowed (so our
>> >>    behavior change here will not be incompatible with GCC).
>> >>
>> >> Our existing behavior is cumbersome:
>> >>
>> >> * Inconsistency between an absolute
>> >>    path (which does not get a ld.  prefix) and a relative path (which
>> gets
>> >>    a ld. prefix) For a relative path, -fuse-ld=dir/foo currently tries
>> to
>> >>    access x86_64-unknown-linux-gnu-ld.dir/foo (if
>> >>    LLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu).
>> >> * lld's new Mach-O port needs to pick an executable name. It would be
>> >>    nice if -fuse-ld= simply accepts a program name, not necessarily
>> prefixed by `ld64.`
>> >>
>> >> I suggest we just hard code the currently used values which intend to
>> get
>> >> a prefix: bfd, gold, lld. For all other values, don't add a prefix.
>> >> (PS4 seems to use -fuse-ld=ps4 but it overrides
>> ToolChain::GetLinkerPath, thus unaffected)
>> >>
>> >> Thoughts?
>> >
>> >
>> > It concerns me that we currently claim to accept arbitrary file paths
>> for -fuse-ld=, yet, we sometimes hardcode special behavior for certain
>> argument values. (Special behavior beyond simply changing which executable
>> name to search for, that is). If we're going to have such conditionals,
>> GCC's behavior of allowing only certain enumerated values would seem to me
>> to be better.
>> >
>> > However, currently, all of the cases in llvm appear to be either related
>> to Windows toolchains or PS4 toolchain. E.g. here
>> https://github.com/llvm/llvm-project/blob/3bb0d95fdc2fffd193d39d14f2ef421d4b468617/clang/lib/Driver/Driver.cpp#L4890
>> and
>> https://github.com/llvm/llvm-project/blob/3bb0d95fdc2fffd193d39d14f2ef421d4b468617/clang/lib/Driver/ToolChains/MinGW.cpp#L424
>> (just search for OPT_fuse_ld_EQ to find others.)
>>
>> Sounds like fixing those is independent of the change you're
>> proposing, though? I'm not sure I see it as related to this proposal.
>
>
>Yes, this is somewhat independent. I bring it up because this proposal is
>to change the existing behavior of -fuse-ld=word, in order to make it more
>consistent with -fuse-ld=path. And also there was a suggestion that GCC
>ought to adopt our behavior.
>
>But, if there's a requirement to understand which kind of linker the driver
>is invoking -- which apparently there is -- this seems a wrong direction to
>go in. And maybe we should instead be deprecating -fuse-ld=PATH. It doesn't
>seem clear to me that there *is* really a fix for this. If the driver needs
>to know what kind of linker it's invoking, then I don't see how it can ever
>work properly to allow arbitrary values.

-fuse-ld= is currently overridden to mean both "linker flavor" and "linker path".

How about this?

* -fuse-ld=bfd => find ld.bfd in COMPILER_PATH
* -fuse-ld=gold => find ld.gold in COMPILER_PATH
* -fuse-ld=lld => find ld.lld in COMPILER_PATH
* -fuse-ld=other => warning: -fuse-ld=.... is deprecated

The need of specifying a relative/absolute path exists (recent request
https://reviews.llvm.org/D80660 ), so we need to add an alternative option, for example

* -fld-path=word  # find word in PATH
* -fld-path=relative/path   # $PWD/relative/path
* -fld-path=/absolute/path   # /absolute/path

>> And the PS4 toolchain driver code already prohibits any -fuse-ld= other
>> than the exact strings "ps4" or "gold", so there's no weird behavior
>> changes, only a clear (yet perhaps unexpected) error message. So, maybe we
>> should do the same for windows? But it's rather unfortunate for clang to
>> inconsistently sometimes allow paths as the argument to -fuse-ld= and
>> sometimes not...
>>
>> Not sure I follow these pieces. Re: PS4, it's good to know it's not an
>> issue/wouldn't be affected by this change. But that doesn't mean other
>> users out there aren't benefiting from/relying on the ld. prefix -
>> it's functionality LLVM has shipped, users can use, etc, and we would
>> be changing that out from under them which I think is always something
>> that should be considered carefully as to what we gain by changing
>> user-facing behavior.
>>
>> Windows: Not sure what part of this discussion would motivate changing
>> windows to disallow the arbitrary linker path compared to allowing it
>> on Linux.
>
>
>The code in LLVM for Windows and PS4 currently needs to know what linker
>it's invoking, for correct behavior. Thus, users who specify -fuse-ld=PATH
>will get incorrect behavior today, even if PATH represents the same binary
>as -fuse-ld=lld would choose.