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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Fangrui Song via cfe-dev
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?
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Fangrui Song via cfe-dev


On Wed, May 20, 2020 at 12:10 PM Fangrui Song via cfe-dev <[hidden email]> 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? 

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

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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 <
>[hidden email]> 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
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Fangrui Song 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" <[hidden email] on behalf of [hidden email]> wrote:

    On 2020-05-20, David Blaikie wrote:
    >On Wed, May 20, 2020 at 12:10 PM Fangrui Song via cfe-dev <
    >[hidden email]> 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
    >> [hidden email]
    >> 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
    [hidden email]
    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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev