[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-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://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.`
>>
>
>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://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>