-Z linker-flavor #40018

japaric · 2017-02-21T22:14:54Z

(Please read the commit message first)

This PR is an alternative to #36120 (internal lld linker). The
main goal of this PR is to make it possible to use LLD as a linker to allow
out of tree experimentation. Now that LLD is going to be shipped with LLVM 4.0,
it should become easier to get a hold of LLD (hopefully, it will be packaged by
Linux distros soon).

Since LLD is a multiarch linker, it has the potential to make cross compilation
easier (less tools need to be installed). Supposedly, LLD is also faster than
the gold linker so LLD may improve build times where link times are significant
(e.g. 100% incremental compilation reuse).

The place where LLD shines is at linking Rust programs that don't depend on
system libraries. For example, here's how you would link a bare metal ARM
Cortex-M program:

$ xargo rustc --target thumbv7m-none-eabi -- -Z linker-flavor=ld -C linker=ld.lld -Z print-link-args
"ld.lld" \
  "-L" \
  "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \
  "$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c.0.o" \
  "-o" \
  "$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c" \
  "--gc-sections" \
  "-L" \
  "$PWD/target/thumbv7m-none-eabi/debug/deps" \
  "-L" \
  "$PWD/target/debug/deps" \
  "-L" \
  "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \
  "-Bstatic" \
  "-Bdynamic" \
  "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib/libcore-11670d2bd4951fa7.rlib"

$ file target/thumbv7m-none-eabi/debug/app
app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped, with debug_info

This doesn't require installing the arm-none-eabi-gcc toolchain.

Even cooler (but I'm biased) is that you can link Rust programs that use
steed (steed is a std re-implementation free of C dependencies for Linux
systems) instead of std for a bunch of different architectures without having
to install a single cross toolchain.

$ xargo rustc --target aarch64-unknown-linux-steed --example hello --release -- -Z print-link-args
"ld.lld" \
  "-L" \
  "$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \
  "$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f.0.o" \
  "-o" \
  "$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f" \
  "--gc-sections" \
  "-L" \
  "$PWD/target/aarch64-unknown-linux-steed/release/deps" \
  "-L" \
  "$PWD/target/release/deps" \
  "-L" \
  "$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \
  "-Bstatic" \
  "-Bdynamic" \
  "/tmp/rustc.lAybk9Ltx93Q/libcompiler_builtins-589aede02de78434.rlib"

$ file target/aarch64-unknown-linux-steed/release/examples/hello
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped, with debug_info

All these targets (architectures) worked with LLD:

The case where lld is unergonomic is linking binaries that depend on system
libraries. Like "Hello, world" for x86_64-unknown-linux-gnu. Because you have
to pass as linker arguments: the path to the startup objects, the path to the
dynamic linker and the library search paths. And all those are system specific
so they can't be encoded in the target itself.

$ cargo \
  rustc \
  --release \
  -- \
  -C \
  linker=ld.lld \
  -Z \
  linker-flavor=ld \
  -C \
  link-args='-dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/usr/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1 /usr/lib/Scrt1.o /usr/lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtbeginS.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtendS.o /usr/lib/crtn.o'

Another case where -Z linker-flavor may come in handy is directly calling
Solaris' linker which is also a multiarch linker (or so I have heard). cc
@binarycrusader

cc @alexcrichton
Heads up: [breaking-change] due to changes in the target specification format.

rust-highfive · 2017-02-21T22:15:11Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @pnkfelix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

binarycrusader · 2017-02-21T22:47:15Z

Yes, the Solaris linker is multi-arch. As long as it is provided well-formed objects it should be able to link them.

With that said, I intend to evaluate what it would take to get lld working on Solaris later this year and teach it some Solaris-specific tricks.

binarycrusader · 2017-02-21T22:48:06Z

Oh, and btw, this is awesome as it will make it easier for us to teach rust how to use the Solaris linker directly.

nagisa · 2017-02-22T07:39:16Z

This kinda collides and duplicates my effort to refactor target specs altogether but since it is pretty similar to what I'm going for wrt linkers I guess it's fine.

nagisa · 2017-02-22T07:42:26Z

The target spec field needn't be required field as it can just default to gnu, just like pretty much everything else does already anyway

binarycrusader · 2017-02-27T17:40:58Z

/cc @dhduvall

alexcrichton · 2017-03-01T15:58:13Z

src/librustc_back/target/mod.rs

+                            "em" => LinkerFlavor::Em,
+                            "gnu" => LinkerFlavor::Gnu,
+                            "ld" => LinkerFlavor::Ld,
+                            "msvc" => LinkerFlavor::Msvc,


These same four strings have been repeated quite a few times throughout this PR, perhaps they could be centralized to one location though?

alexcrichton · 2017-03-01T16:01:02Z

src/librustc_trans/back/linker.rs

+    }
+}
+
+impl<'a> Linker for LdLinker<'a> {


Most of this seems duplicated from a definition above, would it be possible to share code instead of duplicating?

alexcrichton · 2017-03-01T16:02:09Z

src/librustc_back/target/freebsd_base.rs

+        // Always enable NX protection when it is available
+        "-Wl,-z,noexecstack".to_string(),
+    ]);
+
    TargetOptions {
        dynamic_linking: true,
        executables: true,
        target_family: Some("unix".to_string()),
        linker_is_gnu: true,


Is an option like this still needed?

alexcrichton · 2017-03-01T16:03:23Z

This all sounds like a great idea to me, thanks @japaric! I think it's some good internal refactoring regardless as well.

As a minor bikeshed, can we perhaps rename LinkerFlavor::Gnu to LinkerFlavor::Gcc? That should be more explicit that we're expecting a C compiler with gcc-compatible options.

japaric · 2017-03-06T04:27:49Z

These same four strings have been repeated quite a few times throughout this PR, perhaps they could be centralized to one location though?

Done.

Most of this seems duplicated from a definition above, would it be possible to share code instead of duplicating?

I got some deduplication by making LdLinker a wrapper around GccLinker. I could maybe get more deduplication if I create a wrapper around Command that strips -Wl, from arguments ...

Is an option like this still needed?

Yes. GccLinker is like a baseline interface but some aspects of it are tweaked based on the truthtiness of the is_like_osx, is_like_gnu and the is_like_solaris options. We could create more specific Linkers to handle those subtle differences and get right of those flags but then we would have SolarisLdLinker, OsxGccLinker, SolarisGccLinker, GnuGccLinker and GnuLdLinker or something like that.

As a minor bikeshed, can we perhaps rename LinkerFlavor::Gnu to LinkerFlavor::Gcc?

Done

alexcrichton · 2017-03-06T16:59:55Z

Ah yeah for deduplication of gcc/ld I was thinking we could just strip -Wl, and such, otherwise the meaty parts to deduplicate (the version script info, other rpath business, etc) is still duplicated.

Also could the "did you mean ..." be deduplicated as well? Just trying to contain the number of places we have to update when we inevitably add a new flavor of linker :)

Also yeah that's true about is_like_foo is just within the GccLinker for now. Let's leave that as-is for a future cleanup.

alexcrichton · 2017-03-06T17:00:29Z

It also looks like Travis may be failing?

alexcrichton · 2017-03-15T15:03:08Z

ping @japaric

mrhota · 2017-03-20T20:32:59Z

squeaky wheel @japaric

alexcrichton · 2017-03-27T15:13:01Z

Closing due to inactivity, but feel free to resubmit with a rebase!

japaric · 2017-04-05T18:34:54Z

Rebased.

Ah yeah for deduplication of gcc/ld I was thinking we could just strip -Wl

Done. Merged GccLinker and LdLinker into a single GccLinker that decides whether to add the -Wl based on the value of a boolean is_ld field.

Also could the "did you mean ..." be deduplicated as well?

Done.

It also looks like Travis may be failing?

That rmake test should be fixed now.

japaric · 2017-04-06T05:14:25Z

Now that we have the unstable book, should I document -Z linker-flavor in there? Are people likely to look for more info about -Z linker-flavor in there? Note that -Z linker-flavor is not behind a #![]-style feature gate as it's a compiler flag.

I forgot to ask in my previous comment: r? @alexcrichton

bors · 2017-04-06T06:10:21Z

☔ The latest upstream changes (presumably #40805) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2017-04-10T18:00:29Z

⌛ Testing commit e192fb3 with merge 3b5754e...

@binarycrusader

-Z linker-flavor (Please read the commit message first) This PR is an alternative to #36120 (internal lld linker). The main goal of this PR is to make it *possible* to use LLD as a linker to allow out of tree experimentation. Now that LLD is going to be shipped with LLVM 4.0, it should become easier to get a hold of LLD (hopefully, it will be packaged by Linux distros soon). Since LLD is a multiarch linker, it has the potential to make cross compilation easier (less tools need to be installed). Supposedly, LLD is also faster than the gold linker so LLD may improve build times where link times are significant (e.g. 100% incremental compilation reuse). The place where LLD shines is at linking Rust programs that don't depend on system libraries. For example, here's how you would link a bare metal ARM Cortex-M program: ``` $ xargo rustc --target thumbv7m-none-eabi -- -Z linker-flavor=ld -C linker=ld.lld -Z print-link-args "ld.lld" \ "-L" \ "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \ "$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c.0.o" \ "-o" \ "$PWD/target/thumbv7m-none-eabi/debug/deps/app-de1f86df314ad68c" \ "--gc-sections" \ "-L" \ "$PWD/target/thumbv7m-none-eabi/debug/deps" \ "-L" \ "$PWD/target/debug/deps" \ "-L" \ "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib" \ "-Bstatic" \ "-Bdynamic" \ "$XARGO_HOME/lib/rustlib/thumbv7m-none-eabi/lib/libcore-11670d2bd4951fa7.rlib" $ file target/thumbv7m-none-eabi/debug/app app: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped, with debug_info ``` This doesn't require installing the `arm-none-eabi-gcc` toolchain. Even cooler (but I'm biased) is that you can link Rust programs that use [`steed`] (`steed` is a `std` re-implementation free of C dependencies for Linux systems) instead of `std` for a bunch of different architectures without having to install a single cross toolchain. [`steed`]: https://github.com/japaric/steed ``` $ xargo rustc --target aarch64-unknown-linux-steed --example hello --release -- -Z print-link-args "ld.lld" \ "-L" \ "$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \ "$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f.0.o" \ "-o" \ "$PWD/target/aarch64-unknown-linux-steed/release/examples/hello-80c130ad884c0f8f" \ "--gc-sections" \ "-L" \ "$PWD/target/aarch64-unknown-linux-steed/release/deps" \ "-L" \ "$PWD/target/release/deps" \ "-L" \ "$XARGO_HOME/lib/rustlib/aarch64-unknown-linux-steed/lib" \ "-Bstatic" \ "-Bdynamic" \ "/tmp/rustc.lAybk9Ltx93Q/libcompiler_builtins-589aede02de78434.rlib" $ file target/aarch64-unknown-linux-steed/release/examples/hello hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped, with debug_info ``` All these targets (architectures) worked with LLD: - [aarch64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/aarch64-unknown-linux-steed.json) - [arm-unknown-linux-steedeabi](https://github.com/japaric/steed/blob/lld/docker/arm-unknown-linux-steedeabi.json) - [arm-unknown-linux-steedeabihf](https://github.com/japaric/steed/blob/lld/docker/arm-unknown-linux-steedeabihf.json) - [armv7-unknown-linux-steedeabihf](https://github.com/japaric/steed/blob/lld/docker/armv7-unknown-linux-steedeabihf.json) - [i686-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/i686-unknown-linux-steed.json) - [mips-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/mips-unknown-linux-steed.json) - [mipsel-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/mipsel-unknown-linux-steed.json) - [powerpc-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/powerpc-unknown-linux-steed.json) - [powerpc64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/powerpc64-unknown-linux-steed.json) - [x86_64-unknown-linux-steed](https://github.com/japaric/steed/blob/lld/docker/x86_64-unknown-linux-steed.json) --- The case where lld is unergonomic is linking binaries that depend on system libraries. Like "Hello, world" for `x86_64-unknown-linux-gnu`. Because you have to pass as linker arguments: the path to the startup objects, the path to the dynamic linker and the library search paths. And all those are system specific so they can't be encoded in the target itself. ``` $ cargo \ rustc \ --release \ -- \ -C \ linker=ld.lld \ -Z \ linker-flavor=ld \ -C \ link-args='-dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/usr/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1 /usr/lib/Scrt1.o /usr/lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtbeginS.o /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/crtendS.o /usr/lib/crtn.o' ``` --- Another case where `-Z linker-flavor` may come in handy is directly calling Solaris' linker which is also a multiarch linker (or so I have heard). cc @binarycrusader cc @alexcrichton Heads up: [breaking-change] due to changes in the target specification format.

bors · 2017-04-10T20:54:49Z

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 3b5754e to master...

See rust-lang/rust#40018

Looks like the LinkerFlavor change introduced in rust-lang#40018 accidentally uses GCC for the WebAssembly target, causing Rust to never actually pass the post link args to emscripten. This then causes the code to be compiled as asm.js instead of WebAssembly, because the Binaryen tools never run due to the missing linker argument.

Compile WASM as WASM instead of asm.js Looks like the LinkerFlavor change introduced in rust-lang#40018 accidentally uses GCC for the WebAssembly target, causing Rust to never actually pass the post link args to emscripten. This then causes the code to be compiled as asm.js instead of WebAssembly, because the Binaryen tools never run due to the missing linker argument.

This field is now required; see rust-lang/rust#40018

In latest rustc，target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

In latest rustc target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

See rust-lang/rust#40018

tamird · 2017-11-24T18:47:37Z

src/librustc_trans/back/linker.rs

-            self.cmd.arg("-Wl,--whole-archive")
-                    .arg("-l").arg(lib)
-                    .arg("-Wl,--no-whole-archive");
+            self.linker_arg("--whole-archive").cmd.arg("-l").arg(lib);


FYI: this style (e.g. "-l" "System") isn't supported by ld64 on darwin - that linker requires the style "-lSystem". I'm testing a PR that changes this.

rust-highfive assigned pnkfelix Feb 21, 2017

japaric mentioned this pull request Feb 21, 2017

Linking with LLD #39915

Open

alexcrichton reviewed Mar 1, 2017

View reviewed changes

alexcrichton assigned alexcrichton and unassigned pnkfelix Mar 1, 2017

japaric force-pushed the ld branch from 77bf2c9 to 21e2e3f Compare March 6, 2017 04:21

alexcrichton closed this Mar 27, 2017

japaric reopened this Apr 5, 2017

japaric force-pushed the ld branch from 21e2e3f to 6ac1bfc Compare April 5, 2017 18:32

japaric changed the title ~~[RFC] -Z linker-flavor~~ -Z linker-flavor Apr 6, 2017

japaric mentioned this pull request Apr 6, 2017

Package request: Rust and Cargo termux/termux-packages#261

Closed

japaric force-pushed the ld branch from 6ac1bfc to c9c42ee Compare April 6, 2017 15:38

bors merged commit e192fb3 into rust-lang:master Apr 10, 2017

japaric deleted the ld branch April 10, 2017 20:56

This was referenced Apr 10, 2017

Implement optimization fuel and re-enable struct field reordering #40377

Merged

Implement global_asm!() (RFC 1548) #40702

Merged

phil-opp added a commit to phil-opp/blog_os that referenced this pull request Apr 12, 2017

Add the new linker-flavor field to target json

c202937

See rust-lang/rust#40018

CryZe mentioned this pull request Apr 14, 2017

Compile WASM as WASM instead of asm.js #41303

Merged

ghost mentioned this pull request Apr 24, 2017

linker-flavor required intermezzOS/kernel#111

Closed

m4b mentioned this pull request May 3, 2017

-C linker flag is misleading #32721

Closed

hawkw added a commit to hawkw/kernel that referenced this pull request May 21, 2017

Add "linker_flavor": "gcc" to target.json

8834efc

This field is now required; see rust-lang/rust#40018

This was referenced May 21, 2017

Update x86_64-unknown-intermezzos-gnu.json to work with recent changes intermezzOS/kernel#112

Merged

Link the kernel using LLD sos-os/kernel#96

Open

orumin added a commit to orumin/Rust-BareMetal-GBA-Sample that referenced this pull request Jun 17, 2017

target-specification: add option for linker-flavor

e2ef3cc

In latest rustc，target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

orumin added a commit to orumin/Rust-BareMetal-GBA-Sample that referenced this pull request Jun 17, 2017

target-specification: add option for linker-flavor

c4af02a

In latest rustc，target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

orumin added a commit to orumin/Rust-BareMetal-GBA-Sample that referenced this pull request Jun 17, 2017

target-specification: add option for linker-flavor

76d5641

In latest rustc，target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

orumin added a commit to orumin/Rust-BareMetal-GBA-Sample that referenced this pull request Jun 17, 2017

target-specification: add option for linker-flavor

8395726

In latest rustc，target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

orumin added a commit to orumin/Rust-BareMetal-GBA-Sample that referenced this pull request Jun 17, 2017

target-specification: add option for linker-flavor

15fe451

In latest rustc，target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

orumin added a commit to orumin/Rust-BareMetal-GBA-Sample that referenced this pull request Jun 17, 2017

target-specification: add option for linker-flavor

8955640

In latest rustc target specification json file is needed "linker-flavor" for this issue: rust-lang/rust#40018

kevinaboos pushed a commit to theseus-os/Theseus that referenced this pull request Jul 27, 2017

Add the new linker-flavor field to target json

512cfe7

See rust-lang/rust#40018

tamird reviewed Nov 24, 2017

View reviewed changes

rkarp mentioned this pull request Dec 3, 2017

Cross compiling from Windows to Linux japaric/rust-cross#33

Open

japaric mentioned this pull request Apr 8, 2018

Tracking issue for -Z linker-flavor #49794

Closed

leecannon mentioned this pull request Oct 28, 2021

zig cc: unsupported linker args (--as-needed, -Bstatic, -Bdynamic, and more) ziglang/zig#10050

Closed

petrochenkov mentioned this pull request Aug 8, 2022

Implement unstable -Clinker-flavor=gcc:lld for MCP 510 #96827

Closed

pnkfelix mentioned this pull request Mar 16, 2023

-C linker-flavor=clang rust-lang/compiler-team#601

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

-Z linker-flavor #40018

-Z linker-flavor #40018

japaric commented Feb 21, 2017

rust-highfive commented Feb 21, 2017

binarycrusader commented Feb 21, 2017

binarycrusader commented Feb 21, 2017

nagisa commented Feb 22, 2017

nagisa commented Feb 22, 2017

binarycrusader commented Feb 27, 2017

alexcrichton Mar 1, 2017

alexcrichton Mar 1, 2017

alexcrichton Mar 1, 2017

alexcrichton commented Mar 1, 2017

japaric commented Mar 6, 2017

alexcrichton commented Mar 6, 2017

alexcrichton commented Mar 6, 2017

alexcrichton commented Mar 15, 2017

mrhota commented Mar 20, 2017

alexcrichton commented Mar 27, 2017

japaric commented Apr 5, 2017

japaric commented Apr 6, 2017

bors commented Apr 6, 2017

bors commented Apr 10, 2017

bors commented Apr 10, 2017

tamird Nov 24, 2017

-Z linker-flavor #40018

-Z linker-flavor #40018

Conversation

japaric commented Feb 21, 2017

rust-highfive commented Feb 21, 2017

binarycrusader commented Feb 21, 2017

binarycrusader commented Feb 21, 2017

nagisa commented Feb 22, 2017

nagisa commented Feb 22, 2017

binarycrusader commented Feb 27, 2017

alexcrichton Mar 1, 2017

Choose a reason for hiding this comment

alexcrichton Mar 1, 2017

Choose a reason for hiding this comment

alexcrichton Mar 1, 2017

Choose a reason for hiding this comment

alexcrichton commented Mar 1, 2017

japaric commented Mar 6, 2017

alexcrichton commented Mar 6, 2017

alexcrichton commented Mar 6, 2017

alexcrichton commented Mar 15, 2017

mrhota commented Mar 20, 2017

alexcrichton commented Mar 27, 2017

japaric commented Apr 5, 2017

japaric commented Apr 6, 2017

bors commented Apr 6, 2017

bors commented Apr 10, 2017

bors commented Apr 10, 2017

tamird Nov 24, 2017

Choose a reason for hiding this comment