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

[David Blaikie via cfe-dev]

Adding the folks from the code review

On Wed, May 20, 2020 at 12:42 PM Fangrui Song <maskray at google.com> 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://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.

Given the needs of a multiplatform/busyboxed linker like lld, it seems
likely that any future multiplatform linker would probably use this
same sort of prefix going forward.

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

Yep, doesn't seem likely - is the intent to use "-fuse-ld" on non-ELF
platforms and make it easier/possible to write "-fuse-ld=lld-link"
instead of having to provide the full path? (or does that already
work/does using a non-ELF platform already disable the "ld."
prefixing?)

> (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")

Sure enough - though dealing with where we are today is trickier :/

Breaking existing users that depend on this generalized prefixing
seems significant - Sony's the best known/most likely to hit this that
I know of. Hopefully Paul Robinson can speak to that.

If GCC is willing to make the same change, I don't feel too strongly
about this - beyond the existing user breakage (which isn't an
insignificant concern - breaking flag compatibility is something best
avoided) the only future problem I could see (& given we're only
currently living with 3 linkers, this isn't a huge deal) is that if
another linker comes along there will be a subtle difference between
"-fuse-ld=lld" and "-fuse-ld=newlink", at least because a user might
be confused about exactly which binary is being used, in the former
case it's "ld.lld" and in the latter it's "newlink". On top of that if
that if "newlink" busyboxes, and perhaps the original name "newlink"
either defaults to one platform (say MachO mode, like ld64.lld), but
if you want to link for MachO, and busyboxes "ld.newlink" to provide
the ld-compatible version - now you have to write
"-fuse-ld=ld.newlink", but you don't have to do that with gold/etc...

Eh, such is life, perhaps.

If the desire is just to support relative paths, that could be
implemented by trying the prefix version - and if that fails, then
trying it as a relative path? Though I can see value in sort of
deprecating/baking in the prefix support only for the existing users
and forcing all new usage to use the actual executable name.

- Dave

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