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

[Shoaib Meenai via cfe-dev]

I think the behavior change you're proposing makes sense, but I also want to point out that our current plan for the new Mach-O port is to name it ld64.lld as well, to replace the old one and prevent any confusion. We're certainly open to a different name though if people can think of something nicer.

As for why we haven't made the ld64.lld switch already, we were waiting for the new Mach-O port to be a bit more feature complete before doing that, since I believe there are some people using the old port still. We were targeting self-hosting as the milestone after which we'd switch over.

On 5/20/20, 12:43 PM, "cfe-dev on behalf of Fangrui Song via cfe-dev" <cfe-dev-bounces at lists.llvm.org on behalf of cfe-dev at lists.llvm.org> wrote:

    On 2020-05-20, David Blaikie wrote:
    >On Wed, May 20, 2020 at 12:10 PM Fangrui Song via cfe-dev <
    >cfe-dev at lists.llvm.org> wrote:
    >
    >> In https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D80225&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=i8VMYJJ0XWBjnRh78QYx9fwr6fSlLBEMkPjsGRIDbDU&s=CtEvErJQu5F--emEtzW9JeavMEr3T_-5RkEZ9H3mcmQ&e=  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.`
    >>
    >
    >To clarify (it seems like the link between "Mach-O lld needs to pick an
    >executable name" and "it would be nice if -fuse-ld accepts a program name"
    >isn't quite spelled out): By making this change to -fuse-ld it would enable
    >the Mach-O version of lld to be called "lld" rather than "ld64.lld"? Is
    >that the goal?

    The Mach-O port can be named whatever developers like, no need to
    coupled with a `ld64.` prefix.

    I do think of whether -fuse-ld=lld means different things would be a
    nice property: ld.lld (ELF), wasm-ld (wasm), lld-link (COFF) in
    different contexts. I realized it is not. The linker options on
    different binary formats are very different. Targeting different binary
    formats requires one to customize the linker options anyway, a common
    -fuse-ld=lld does not save much.

    (In 2010, it might be cleaner if binutils did not install ld.bfd -> ld
    and ld.gold -> gold ...... They could juse use -fuse-ld=ld to mean "ld"
    and -fuse-ld=gold to mean "gold")

    >Is Mach-O lld likely to need different command line compatibility than ELF
    >or COFF lld? It seems like having a distinct name to enable detection of
    >what command line support/object file format assumptions/other behavior
    >changes compared to ELF/COFF may be useful, and "ld64.lld" is probably as
    >good a name as any, if that functionality is desirable?
    >
    >>
    >> 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?
    >> _______________________________________________
    >> cfe-dev mailing list
    >> cfe-dev at lists.llvm.org
    >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=i8VMYJJ0XWBjnRh78QYx9fwr6fSlLBEMkPjsGRIDbDU&s=-nxqmk9HmoPzdCDZ62Q0xnZRbCsVXu2IRbOPwzM21mM&e= 
    >>
    _______________________________________________
    cfe-dev mailing list
    cfe-dev at lists.llvm.org
    https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=i8VMYJJ0XWBjnRh78QYx9fwr6fSlLBEMkPjsGRIDbDU&s=-nxqmk9HmoPzdCDZ62Q0xnZRbCsVXu2IRbOPwzM21mM&e=