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

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