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

Mon Jul 6 14:32:34 PDT 2020

As far as I know, -fuse-ld has been copied from gcc, which documents it here: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-fuse-ld_003dbfd <https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-fuse-ld_003dbfd>. Obviously we can make any alias we want, but the gcc spelling should still be supported.

-Dimitry

> On 6 Jul 2020, at 21:52, Petr Hosek via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> -f<flag> options are typically used for flags that control code generation, that's what https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html <https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html> says as well. Neither of these flags are related to code generation. Have you considered using just -use-ld= and -ld-path= and deprecating -fuse-ld= altogether? I think that would also be more consistent with other --*-path flags we have such as --cuda-path= or ptxas-path=.
> 
> On Mon, Jul 6, 2020 at 12:36 PM Fangrui Song via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> On 2020-07-06, David Blaikie wrote:
> >The design then is to support composing -fuse-ld and -fld-path? So
> >things like -fuse-ld=gold
> >-fld-path=some-thing-like-gold-but-maybe-not-quite (if I want the
> >clang driver gold-specific behavior, but to use my custom linker
> >binary?)?
> 
> Yes. -fuse-ld= specifies the flavor: bfd, gold, lld.
> This can affect clang driver decisions on linker options.
> (see https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Fuchsia.cpp#L57 <https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Fuchsia.cpp#L57> )
> 
> When -fuse-ld=lld is specified, you can still specify
> -fld-path= to use a non-standard path, e.g.  -fuse-ld=lld -fld-path=/tmp/opt/bin/ld.lld
> 
> >On Wed, Jul 1, 2020 at 5:54 PM Fangrui Song via cfe-dev
> ><cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >>
> >> On 2020-06-16, Fangrui Song wrote:
> >> >On 2020-06-03, Fangrui Song wrote:
> >> >>On 2020-06-03, David Chisnall via cfe-dev wrote:
> >> >>>On 02/06/2020 19:47, Fangrui Song via cfe-dev wrote:
> >> >>>>If they use a relative path, they can't be benefiting from ld. prefix
> >> >>>
> >> >>>This depends on how they specify the path.  If they specify a path
> >> >>>for the linker via -fuse-ld, they don't get the prefix.  Most
> >> >>>cross-compile toolchains that I've seen don't do that.  Instead,
> >> >>>they use -B to specify a path to find *all* of the tools and then
> >> >>>use -fuse-ld={lld,gold,bfd,proprietary linker's name}.
> >> >>>
> >> >>>That is the use case I'm concerned about breaking.  The behaviour
> >> >>>of -B is to prepend a search path, but still fall back to the
> >> >>>default paths if a tool is not found there.  For example, if I
> >> >>>have:
> >> >>>
> >> >>>/usr/bin/lld
> >> >>>/my/custom/sdk/bin/ld.lld
> >> >>>
> >> >>>If I run:
> >> >>>
> >> >>>$ clang -B /my/custom/sdk/bin/ -fuse-ld=lld ...
> >> >>>
> >> >>>Today, I will run my cross-compile toolchain's linker.  With your
> >> >>>proposed change, I will run my system LLD install.  As a user, I
> >> >>>will see very confusing error messages from the system linker if
> >> >>>it can't handle my cross-compile target.  Worse, I may see a
> >> >>>binary linked with a linker that defaults to a different linker
> >> >>>script, but still produces some output.
> >> >>>
> >> >>>David
> >> >>
> >> >>-fuse-ld={bfd,gold,lld} is compatible with the previous behavior.
> >> >>
> >> >>Do you propose that:
> >> >>
> >> >>* -fuse-ld={bfd,gold.lld} should find "ld.{bfd,gold,lld}" in COMPILER_PATH
> >> >>* all -fuse-ld=word should find "word" in COMPILER_PATH
> >> >>* -fuse-ld=relative/path should find "relative/path" in PATH?
> >> >
> >> >Thoughts?
> >>
> >> Created https://reviews.llvm.org/D83015 <https://reviews.llvm.org/D83015> [Driver] Add -fld-path= and deprecate -fuse-ld=/abs/path and -fuse-ld=rel/path
> >>
> >> This should resolve jyknight's concern.
> >>
> >> I think GCC will be happy with whatever reasonable consensus we can reach:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549236.html <https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549236.html>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200706/c2cf11d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200706/c2cf11d5/attachment.sig>