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

[James Y Knight via cfe-dev]

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

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200602/a4595c48/attachment.html>