<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 20, 2020 at 12:10 PM Fangrui Song via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In <a href="https://reviews.llvm.org/D80225" rel="noreferrer" target="_blank">https://reviews.llvm.org/D80225</a> I intended to update the semantics of -fuse-ld=<br>
Some context (from my archaeology) about the option<br>
<br>
* <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470</a> added support for -fuse-ld=bfd to mean ld.bfd and -fuse-ld=gold to mean ld.gold<br>
* rL194328 ported the feature and made -fuse-ld= available for other values (with the ld. prefix)<br>
* D78290 changed the prefix to ld64. on Darwin.<br>
* GCC added support for -fuse-ld=lld. No other value than bfd,gold,lld is allowed (so our<br>
   behavior change here will not be incompatible with GCC).<br>
<br>
Our existing behavior is cumbersome:<br>
<br>
* Inconsistency between an absolute<br>
   path (which does not get a ld.  prefix) and a relative path (which gets<br>
   a ld. prefix) For a relative path, -fuse-ld=dir/foo currently tries to<br>
   access x86_64-unknown-linux-gnu-ld.dir/foo (if<br>
   LLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu).<br>
* lld's new Mach-O port needs to pick an executable name. It would be<br>
   nice if -fuse-ld= simply accepts a program name, not necessarily prefixed by `ld64.`<br></blockquote><div><br></div><div>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? <br><br>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I suggest we just hard code the currently used values which intend to get<br>
a prefix: bfd, gold, lld. For all other values, don't add a prefix.<br>
(PS4 seems to use -fuse-ld=ps4 but it overrides ToolChain::GetLinkerPath, thus unaffected)<br>
<br>
Thoughts?<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>