2018-10-23 17:01:35 +02:00
|
|
|
use super::archive;
|
2019-12-22 17:42:04 -05:00
|
|
|
use super::command::Command;
|
|
|
|
use super::symbol_export;
|
2020-06-23 09:41:56 -07:00
|
|
|
use rustc_span::symbol::sym;
|
2018-10-23 17:01:35 +02:00
|
|
|
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
use std::ffi::{OsStr, OsString};
|
2015-07-28 17:19:08 -07:00
|
|
|
use std::fs::{self, File};
|
|
|
|
use std::io::prelude::*;
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-22 17:07:11 -07:00
|
|
|
use std::io::{self, BufWriter};
|
2020-04-05 02:58:32 +03:00
|
|
|
use std::mem;
|
2015-05-08 15:31:23 -07:00
|
|
|
use std::path::{Path, PathBuf};
|
|
|
|
|
2020-03-11 12:49:08 +01:00
|
|
|
use rustc_data_structures::fx::FxHashMap;
|
2020-01-05 02:37:57 +01:00
|
|
|
use rustc_hir::def_id::{CrateNum, LOCAL_CRATE};
|
2020-03-29 17:19:48 +02:00
|
|
|
use rustc_middle::middle::dependency_format::Linkage;
|
|
|
|
use rustc_middle::ty::TyCtxt;
|
2019-07-23 18:50:47 +03:00
|
|
|
use rustc_serialize::{json, Encoder};
|
2020-05-03 12:36:12 +08:00
|
|
|
use rustc_session::config::{self, CrateType, DebugInfo, LinkerPluginLto, Lto, OptLevel, Strip};
|
2020-03-11 12:49:08 +01:00
|
|
|
use rustc_session::Session;
|
2020-01-01 19:30:57 +01:00
|
|
|
use rustc_span::symbol::Symbol;
|
2020-05-02 02:22:48 +03:00
|
|
|
use rustc_target::spec::{LinkOutputKind, LinkerFlavor, LldFlavor};
|
2016-05-25 01:45:25 +03:00
|
|
|
|
2020-04-27 23:37:57 +03:00
|
|
|
/// Disables non-English messages from localized linkers.
|
|
|
|
/// Such messages may cause issues with text encoding on Windows (#35785)
|
|
|
|
/// and prevent inspection of linker output in case of errors, which we occasionally do.
|
|
|
|
/// This should be acceptable because other messages from rustc are in English anyway,
|
|
|
|
/// and may also be desirable to improve searchability of the linker diagnostics.
|
|
|
|
pub fn disable_localization(linker: &mut Command) {
|
|
|
|
// No harm in setting both env vars simultaneously.
|
|
|
|
// Unix-style linkers.
|
2020-07-18 16:59:16 +02:00
|
|
|
linker.env("LC_ALL", "C");
|
2020-04-27 23:37:57 +03:00
|
|
|
// MSVC's `link.exe`.
|
|
|
|
linker.env("VSLANG", "1033");
|
|
|
|
}
|
|
|
|
|
2016-05-25 01:45:25 +03:00
|
|
|
/// For all the linkers we support, and information they might
|
|
|
|
/// need out of the shared crate context before we get rid of it.
|
2020-06-11 15:49:57 +01:00
|
|
|
#[derive(Encodable, Decodable)]
|
2016-05-25 01:45:25 +03:00
|
|
|
pub struct LinkerInfo {
|
2018-08-18 13:55:43 +03:00
|
|
|
exports: FxHashMap<CrateType, Vec<String>>,
|
2016-05-25 01:45:25 +03:00
|
|
|
}
|
|
|
|
|
2017-09-13 13:22:20 -07:00
|
|
|
impl LinkerInfo {
|
2019-06-14 00:48:52 +03:00
|
|
|
pub fn new(tcx: TyCtxt<'_>) -> LinkerInfo {
|
2016-05-25 01:45:25 +03:00
|
|
|
LinkerInfo {
|
2019-12-22 17:42:04 -05:00
|
|
|
exports: tcx
|
|
|
|
.sess
|
2020-05-15 21:44:28 -07:00
|
|
|
.crate_types()
|
2019-12-22 17:42:04 -05:00
|
|
|
.iter()
|
|
|
|
.map(|&c| (c, exported_symbols(tcx, c)))
|
|
|
|
.collect(),
|
2016-05-25 01:45:25 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-20 14:45:08 +02:00
|
|
|
pub fn to_linker<'a>(
|
|
|
|
&'a self,
|
|
|
|
cmd: Command,
|
|
|
|
sess: &'a Session,
|
|
|
|
flavor: LinkerFlavor,
|
|
|
|
target_cpu: &'a str,
|
2019-12-22 17:42:04 -05:00
|
|
|
) -> Box<dyn Linker + 'a> {
|
2018-07-06 00:41:42 -05:00
|
|
|
match flavor {
|
2019-12-22 17:42:04 -05:00
|
|
|
LinkerFlavor::Lld(LldFlavor::Link) | LinkerFlavor::Msvc => {
|
|
|
|
Box::new(MsvcLinker { cmd, sess, info: self }) as Box<dyn Linker>
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
}
|
2019-12-22 17:42:04 -05:00
|
|
|
LinkerFlavor::Em => Box::new(EmLinker { cmd, sess, info: self }) as Box<dyn Linker>,
|
|
|
|
LinkerFlavor::Gcc => Box::new(GccLinker {
|
|
|
|
cmd,
|
|
|
|
sess,
|
|
|
|
info: self,
|
|
|
|
hinted_static: false,
|
|
|
|
is_ld: false,
|
|
|
|
target_cpu,
|
|
|
|
}) as Box<dyn Linker>,
|
|
|
|
|
|
|
|
LinkerFlavor::Lld(LldFlavor::Ld)
|
|
|
|
| LinkerFlavor::Lld(LldFlavor::Ld64)
|
|
|
|
| LinkerFlavor::Ld => Box::new(GccLinker {
|
|
|
|
cmd,
|
|
|
|
sess,
|
|
|
|
info: self,
|
|
|
|
hinted_static: false,
|
|
|
|
is_ld: true,
|
|
|
|
target_cpu,
|
|
|
|
}) as Box<dyn Linker>,
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
|
|
|
LinkerFlavor::Lld(LldFlavor::Wasm) => {
|
2019-01-04 07:54:33 -08:00
|
|
|
Box::new(WasmLd::new(cmd, sess, self)) as Box<dyn Linker>
|
2017-10-22 20:01:00 -07:00
|
|
|
}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
LinkerFlavor::PtxLinker => Box::new(PtxLinker { cmd, sess }) as Box<dyn Linker>,
|
2016-05-25 01:45:25 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
|
2019-02-08 14:53:55 +01:00
|
|
|
/// Linker abstraction used by `back::link` to build up the command to invoke a
|
2015-05-08 15:31:23 -07:00
|
|
|
/// linker.
|
|
|
|
///
|
|
|
|
/// This trait is the total list of requirements needed by `back::link` and
|
|
|
|
/// represents the meaning of each option being passed down. This trait is then
|
|
|
|
/// used to dispatch on whether a GNU-like linker (generally `ld.exe`) or an
|
2018-11-27 02:59:49 +00:00
|
|
|
/// MSVC linker (e.g., `link.exe`) is being used.
|
2015-05-08 15:31:23 -07:00
|
|
|
pub trait Linker {
|
2020-04-05 02:11:29 +03:00
|
|
|
fn cmd(&mut self) -> &mut Command;
|
2020-05-02 02:22:48 +03:00
|
|
|
fn set_output_kind(&mut self, output_kind: LinkOutputKind, out_filename: &Path);
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_dylib(&mut self, lib: Symbol);
|
|
|
|
fn link_rust_dylib(&mut self, lib: Symbol, path: &Path);
|
|
|
|
fn link_framework(&mut self, framework: Symbol);
|
|
|
|
fn link_staticlib(&mut self, lib: Symbol);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn link_rlib(&mut self, lib: &Path);
|
2015-07-07 21:33:44 -07:00
|
|
|
fn link_whole_rlib(&mut self, lib: &Path);
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_whole_staticlib(&mut self, lib: Symbol, search_path: &[PathBuf]);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn include_path(&mut self, path: &Path);
|
|
|
|
fn framework_path(&mut self, path: &Path);
|
|
|
|
fn output_filename(&mut self, path: &Path);
|
|
|
|
fn add_object(&mut self, path: &Path);
|
2016-05-10 14:17:57 -07:00
|
|
|
fn gc_sections(&mut self, keep_metadata: bool);
|
2017-07-10 20:57:45 +02:00
|
|
|
fn full_relro(&mut self);
|
2018-02-22 21:28:20 +01:00
|
|
|
fn partial_relro(&mut self);
|
|
|
|
fn no_relro(&mut self);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn optimize(&mut self);
|
2018-03-19 22:29:58 +01:00
|
|
|
fn pgo_gen(&mut self);
|
2020-01-13 13:25:39 +00:00
|
|
|
fn control_flow_guard(&mut self);
|
2020-05-03 12:36:12 +08:00
|
|
|
fn debuginfo(&mut self, strip: Strip);
|
2020-04-29 20:47:07 +03:00
|
|
|
fn no_crt_objects(&mut self);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn no_default_libraries(&mut self);
|
2016-05-25 01:45:25 +03:00
|
|
|
fn export_symbols(&mut self, tmpdir: &Path, crate_type: CrateType);
|
2016-10-31 09:36:30 -07:00
|
|
|
fn subsystem(&mut self, subsystem: &str);
|
2018-03-23 14:33:22 -07:00
|
|
|
fn group_start(&mut self);
|
|
|
|
fn group_end(&mut self);
|
2019-02-01 15:15:43 +01:00
|
|
|
fn linker_plugin_lto(&mut self);
|
2020-06-20 23:26:24 +03:00
|
|
|
fn add_eh_frame_header(&mut self) {}
|
2021-03-28 00:02:23 +03:00
|
|
|
fn add_as_needed(&mut self) {}
|
2020-04-05 02:58:32 +03:00
|
|
|
fn finalize(&mut self);
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
|
2020-04-05 02:11:29 +03:00
|
|
|
impl dyn Linker + '_ {
|
|
|
|
pub fn arg(&mut self, arg: impl AsRef<OsStr>) {
|
|
|
|
self.cmd().arg(arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn args(&mut self, args: impl IntoIterator<Item: AsRef<OsStr>>) {
|
|
|
|
self.cmd().args(args);
|
|
|
|
}
|
2020-04-05 02:58:32 +03:00
|
|
|
|
|
|
|
pub fn take_cmd(&mut self) -> Command {
|
|
|
|
mem::replace(self.cmd(), Command::new(""))
|
|
|
|
}
|
2020-04-05 02:11:29 +03:00
|
|
|
}
|
|
|
|
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
pub struct GccLinker<'a> {
|
2017-03-23 18:03:39 -07:00
|
|
|
cmd: Command,
|
2016-05-25 01:45:25 +03:00
|
|
|
sess: &'a Session,
|
2017-03-23 18:03:39 -07:00
|
|
|
info: &'a LinkerInfo,
|
|
|
|
hinted_static: bool, // Keeps track of the current hinting mode.
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
// Link as ld
|
|
|
|
is_ld: bool,
|
2018-10-20 14:45:08 +02:00
|
|
|
target_cpu: &'a str,
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
impl<'a> GccLinker<'a> {
|
|
|
|
/// Argument that must be passed *directly* to the linker
|
|
|
|
///
|
2019-02-08 14:53:55 +01:00
|
|
|
/// These arguments need to be prepended with `-Wl`, when a GCC-style linker is used.
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
fn linker_arg<S>(&mut self, arg: S) -> &mut Self
|
2019-12-22 17:42:04 -05:00
|
|
|
where
|
|
|
|
S: AsRef<OsStr>,
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
{
|
|
|
|
if !self.is_ld {
|
|
|
|
let mut os = OsString::from("-Wl,");
|
|
|
|
os.push(arg.as_ref());
|
|
|
|
self.cmd.arg(os);
|
|
|
|
} else {
|
|
|
|
self.cmd.arg(arg);
|
|
|
|
}
|
|
|
|
self
|
|
|
|
}
|
|
|
|
|
2015-05-08 15:31:23 -07:00
|
|
|
fn takes_hints(&self) -> bool {
|
2019-03-19 13:06:37 -07:00
|
|
|
// Really this function only returns true if the underlying linker
|
|
|
|
// configured for a compiler is binutils `ld.bfd` and `ld.gold`. We
|
|
|
|
// don't really have a foolproof way to detect that, so rule out some
|
|
|
|
// platforms where currently this is guaranteed to *not* be the case:
|
|
|
|
//
|
|
|
|
// * On OSX they have their own linker, not binutils'
|
|
|
|
// * For WebAssembly the only functional linker is LLD, which doesn't
|
|
|
|
// support hint flags
|
2020-11-08 14:27:51 +03:00
|
|
|
!self.sess.target.is_like_osx && self.sess.target.arch != "wasm32"
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
|
|
|
|
// Some platforms take hints about whether a library is static or dynamic.
|
|
|
|
// For those that support this, we ensure we pass the option if the library
|
|
|
|
// was flagged "static" (most defaults are dynamic) to ensure that if
|
|
|
|
// libfoo.a and libfoo.so both exist that the right one is chosen.
|
|
|
|
fn hint_static(&mut self) {
|
2019-12-22 17:42:04 -05:00
|
|
|
if !self.takes_hints() {
|
|
|
|
return;
|
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
if !self.hinted_static {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("-Bstatic");
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hinted_static = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn hint_dynamic(&mut self) {
|
2019-12-22 17:42:04 -05:00
|
|
|
if !self.takes_hints() {
|
|
|
|
return;
|
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
if self.hinted_static {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("-Bdynamic");
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hinted_static = false;
|
|
|
|
}
|
|
|
|
}
|
2018-07-03 16:33:11 +02:00
|
|
|
|
2019-02-01 15:15:43 +01:00
|
|
|
fn push_linker_plugin_lto_args(&mut self, plugin_path: Option<&OsStr>) {
|
2018-07-03 16:33:11 +02:00
|
|
|
if let Some(plugin_path) = plugin_path {
|
|
|
|
let mut arg = OsString::from("-plugin=");
|
|
|
|
arg.push(plugin_path);
|
|
|
|
self.linker_arg(&arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
let opt_level = match self.sess.opts.optimize {
|
|
|
|
config::OptLevel::No => "O0",
|
|
|
|
config::OptLevel::Less => "O1",
|
2020-08-26 22:11:53 +02:00
|
|
|
config::OptLevel::Default | config::OptLevel::Size | config::OptLevel::SizeMin => "O2",
|
2018-07-03 16:33:11 +02:00
|
|
|
config::OptLevel::Aggressive => "O3",
|
|
|
|
};
|
|
|
|
|
|
|
|
self.linker_arg(&format!("-plugin-opt={}", opt_level));
|
2018-10-20 14:45:08 +02:00
|
|
|
let target_cpu = self.target_cpu;
|
|
|
|
self.linker_arg(&format!("-plugin-opt=mcpu={}", target_cpu));
|
2018-07-03 16:33:11 +02:00
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
|
|
|
|
fn build_dylib(&mut self, out_filename: &Path) {
|
|
|
|
// On mac we need to tell the linker to let this library be rpathed
|
2020-11-08 14:27:51 +03:00
|
|
|
if self.sess.target.is_like_osx {
|
2020-05-02 02:22:48 +03:00
|
|
|
self.cmd.arg("-dynamiclib");
|
|
|
|
self.linker_arg("-dylib");
|
|
|
|
|
|
|
|
// Note that the `osx_rpath_install_name` option here is a hack
|
|
|
|
// purely to support rustbuild right now, we should get a more
|
|
|
|
// principled solution at some point to force the compiler to pass
|
|
|
|
// the right `-Wl,-install_name` with an `@rpath` in it.
|
|
|
|
if self.sess.opts.cg.rpath || self.sess.opts.debugging_opts.osx_rpath_install_name {
|
|
|
|
self.linker_arg("-install_name");
|
|
|
|
let mut v = OsString::from("@rpath/");
|
|
|
|
v.push(out_filename.file_name().unwrap());
|
|
|
|
self.linker_arg(&v);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
self.cmd.arg("-shared");
|
2020-11-08 14:27:51 +03:00
|
|
|
if self.sess.target.is_like_windows {
|
2020-05-02 02:22:48 +03:00
|
|
|
// The output filename already contains `dll_suffix` so
|
|
|
|
// the resulting import library will have a name in the
|
|
|
|
// form of libfoo.dll.a
|
|
|
|
let implib_name =
|
|
|
|
out_filename.file_name().and_then(|file| file.to_str()).map(|file| {
|
|
|
|
format!(
|
|
|
|
"{}{}{}",
|
2020-11-08 14:27:51 +03:00
|
|
|
self.sess.target.staticlib_prefix,
|
2020-05-02 02:22:48 +03:00
|
|
|
file,
|
2020-11-08 14:27:51 +03:00
|
|
|
self.sess.target.staticlib_suffix
|
2020-05-02 02:22:48 +03:00
|
|
|
)
|
|
|
|
});
|
|
|
|
if let Some(implib_name) = implib_name {
|
|
|
|
let implib = out_filename.parent().map(|dir| dir.join(&implib_name));
|
|
|
|
if let Some(implib) = implib {
|
2020-08-16 21:54:37 +02:00
|
|
|
self.linker_arg(&format!("--out-implib={}", (*implib).to_str().unwrap()));
|
2020-05-02 02:22:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
impl<'a> Linker for GccLinker<'a> {
|
2020-04-05 02:11:29 +03:00
|
|
|
fn cmd(&mut self) -> &mut Command {
|
|
|
|
&mut self.cmd
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
|
|
|
|
fn set_output_kind(&mut self, output_kind: LinkOutputKind, out_filename: &Path) {
|
|
|
|
match output_kind {
|
|
|
|
LinkOutputKind::DynamicNoPicExe => {
|
2020-11-08 14:27:51 +03:00
|
|
|
if !self.is_ld && self.sess.target.linker_is_gnu {
|
2020-05-02 02:22:48 +03:00
|
|
|
self.cmd.arg("-no-pie");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
LinkOutputKind::DynamicPicExe => {
|
|
|
|
// `-pie` works for both gcc wrapper and ld.
|
|
|
|
self.cmd.arg("-pie");
|
|
|
|
}
|
|
|
|
LinkOutputKind::StaticNoPicExe => {
|
|
|
|
// `-static` works for both gcc wrapper and ld.
|
|
|
|
self.cmd.arg("-static");
|
2020-11-08 14:27:51 +03:00
|
|
|
if !self.is_ld && self.sess.target.linker_is_gnu {
|
2020-05-02 02:22:48 +03:00
|
|
|
self.cmd.arg("-no-pie");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
LinkOutputKind::StaticPicExe => {
|
|
|
|
if !self.is_ld {
|
|
|
|
// Note that combination `-static -pie` doesn't work as expected
|
|
|
|
// for the gcc wrapper, `-static` in that case suppresses `-pie`.
|
|
|
|
self.cmd.arg("-static-pie");
|
|
|
|
} else {
|
|
|
|
// `--no-dynamic-linker` and `-z text` are not strictly necessary for producing
|
|
|
|
// a static pie, but currently passed because gcc and clang pass them.
|
|
|
|
// The former suppresses the `INTERP` ELF header specifying dynamic linker,
|
|
|
|
// which is otherwise implicitly injected by ld (but not lld).
|
|
|
|
// The latter doesn't change anything, only ensures that everything is pic.
|
|
|
|
self.cmd.args(&["-static", "-pie", "--no-dynamic-linker", "-z", "text"]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
LinkOutputKind::DynamicDylib => self.build_dylib(out_filename),
|
|
|
|
LinkOutputKind::StaticDylib => {
|
|
|
|
self.cmd.arg("-static");
|
|
|
|
self.build_dylib(out_filename);
|
|
|
|
}
|
2020-12-12 21:38:23 -06:00
|
|
|
LinkOutputKind::WasiReactorExe => {
|
|
|
|
self.linker_arg("--entry");
|
|
|
|
self.linker_arg("_initialize");
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
}
|
2020-05-30 17:03:50 +03:00
|
|
|
// VxWorks compiler driver introduced `--static-crt` flag specifically for rustc,
|
|
|
|
// it switches linking for libc and similar system libraries to static without using
|
|
|
|
// any `#[link]` attributes in the `libc` crate, see #72782 for details.
|
|
|
|
// FIXME: Switch to using `#[link]` attributes in the `libc` crate
|
|
|
|
// similarly to other targets.
|
2020-11-08 14:57:55 +03:00
|
|
|
if self.sess.target.os == "vxworks"
|
2020-05-30 17:03:50 +03:00
|
|
|
&& matches!(
|
|
|
|
output_kind,
|
|
|
|
LinkOutputKind::StaticNoPicExe
|
|
|
|
| LinkOutputKind::StaticPicExe
|
|
|
|
| LinkOutputKind::StaticDylib
|
|
|
|
)
|
|
|
|
{
|
|
|
|
self.cmd.arg("--static-crt");
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_dylib(&mut self, lib: Symbol) {
|
|
|
|
self.hint_dynamic();
|
|
|
|
self.cmd.arg(format!("-l{}", lib));
|
|
|
|
}
|
|
|
|
fn link_staticlib(&mut self, lib: Symbol) {
|
|
|
|
self.hint_static();
|
|
|
|
self.cmd.arg(format!("-l{}", lib));
|
2018-07-24 00:47:34 +01:00
|
|
|
}
|
2019-12-22 17:42:04 -05:00
|
|
|
fn link_rlib(&mut self, lib: &Path) {
|
|
|
|
self.hint_static();
|
|
|
|
self.cmd.arg(lib);
|
|
|
|
}
|
|
|
|
fn include_path(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-L").arg(path);
|
|
|
|
}
|
|
|
|
fn framework_path(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-F").arg(path);
|
|
|
|
}
|
|
|
|
fn output_filename(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-o").arg(path);
|
|
|
|
}
|
|
|
|
fn add_object(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg(path);
|
|
|
|
}
|
|
|
|
fn full_relro(&mut self) {
|
|
|
|
self.linker_arg("-zrelro");
|
|
|
|
self.linker_arg("-znow");
|
|
|
|
}
|
|
|
|
fn partial_relro(&mut self) {
|
|
|
|
self.linker_arg("-zrelro");
|
|
|
|
}
|
|
|
|
fn no_relro(&mut self) {
|
|
|
|
self.linker_arg("-znorelro");
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_rust_dylib(&mut self, lib: Symbol, _path: &Path) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_dynamic();
|
2018-10-06 11:37:28 +02:00
|
|
|
self.cmd.arg(format!("-l{}", lib));
|
2015-06-25 00:33:52 -07:00
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_framework(&mut self, framework: Symbol) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_dynamic();
|
2019-09-05 11:23:45 +10:00
|
|
|
self.cmd.arg("-framework").sym_arg(framework);
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
|
2017-03-23 18:03:39 -07:00
|
|
|
// Here we explicitly ask that the entire archive is included into the
|
|
|
|
// result artifact. For more details see #15460, but the gist is that
|
|
|
|
// the linker will strip away any unused objects in the archive if we
|
|
|
|
// don't otherwise explicitly reference them. This can occur for
|
|
|
|
// libraries which are just providing bindings, libraries with generic
|
|
|
|
// functions, etc.
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_whole_staticlib(&mut self, lib: Symbol, search_path: &[PathBuf]) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_static();
|
2020-10-15 11:44:00 +02:00
|
|
|
let target = &self.sess.target;
|
2020-11-08 14:27:51 +03:00
|
|
|
if !target.is_like_osx {
|
2018-10-06 11:37:28 +02:00
|
|
|
self.linker_arg("--whole-archive").cmd.arg(format!("-l{}", lib));
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("--no-whole-archive");
|
2015-05-08 15:31:23 -07:00
|
|
|
} else {
|
2017-03-12 14:13:35 -04:00
|
|
|
// -force_load is the macOS equivalent of --whole-archive, but it
|
2015-05-08 15:31:23 -07:00
|
|
|
// involves passing the full path to the library to link.
|
2018-07-24 00:47:34 +01:00
|
|
|
self.linker_arg("-force_load");
|
2018-10-23 17:01:35 +02:00
|
|
|
let lib = archive::find_library(lib, search_path, &self.sess);
|
2018-07-24 00:47:34 +01:00
|
|
|
self.linker_arg(&lib);
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-07 21:33:44 -07:00
|
|
|
fn link_whole_rlib(&mut self, lib: &Path) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_static();
|
2020-11-08 14:27:51 +03:00
|
|
|
if self.sess.target.is_like_osx {
|
2018-07-24 00:47:34 +01:00
|
|
|
self.linker_arg("-force_load");
|
|
|
|
self.linker_arg(&lib);
|
2015-07-07 21:33:44 -07:00
|
|
|
} else {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("--whole-archive").cmd.arg(lib);
|
|
|
|
self.linker_arg("--no-whole-archive");
|
2015-07-07 21:33:44 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-10 14:17:57 -07:00
|
|
|
fn gc_sections(&mut self, keep_metadata: bool) {
|
2015-05-08 15:31:23 -07:00
|
|
|
// The dead_strip option to the linker specifies that functions and data
|
|
|
|
// unreachable by the entry point will be removed. This is quite useful
|
|
|
|
// with Rust's compilation model of compiling libraries at a time into
|
|
|
|
// one object file. For example, this brings hello world from 1.7MB to
|
|
|
|
// 458K.
|
|
|
|
//
|
|
|
|
// Note that this is done for both executables and dynamic libraries. We
|
|
|
|
// won't get much benefit from dylibs because LLVM will have already
|
|
|
|
// stripped away as much as it could. This has not been seen to impact
|
|
|
|
// link times negatively.
|
|
|
|
//
|
|
|
|
// -dead_strip can't be part of the pre_link_args because it's also used
|
|
|
|
// for partial linking when using multiple codegen units (-r). So we
|
|
|
|
// insert it here.
|
2020-11-08 14:27:51 +03:00
|
|
|
if self.sess.target.is_like_osx {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("-dead_strip");
|
2020-11-08 14:27:51 +03:00
|
|
|
} else if self.sess.target.is_like_solaris {
|
2018-07-24 00:47:34 +01:00
|
|
|
self.linker_arg("-zignore");
|
2015-05-08 15:31:23 -07:00
|
|
|
|
|
|
|
// If we're building a dylib, we don't use --gc-sections because LLVM
|
|
|
|
// has already done the best it can do, and we also don't want to
|
|
|
|
// eliminate the metadata. If we're building an executable, however,
|
|
|
|
// --gc-sections drops the size of hello world from 1.8MB to 597K, a 67%
|
|
|
|
// reduction.
|
2016-05-10 14:17:57 -07:00
|
|
|
} else if !keep_metadata {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("--gc-sections");
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn optimize(&mut self) {
|
2020-11-08 14:27:51 +03:00
|
|
|
if !self.sess.target.linker_is_gnu {
|
2019-12-22 17:42:04 -05:00
|
|
|
return;
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
|
|
|
|
// GNU-style linkers support optimization with -O. GNU ld doesn't
|
|
|
|
// need a numeric argument, but other linkers do.
|
2019-12-22 17:42:04 -05:00
|
|
|
if self.sess.opts.optimize == config::OptLevel::Default
|
|
|
|
|| self.sess.opts.optimize == config::OptLevel::Aggressive
|
|
|
|
{
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
self.linker_arg("-O1");
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-19 22:29:58 +01:00
|
|
|
fn pgo_gen(&mut self) {
|
2020-11-08 14:27:51 +03:00
|
|
|
if !self.sess.target.linker_is_gnu {
|
2019-12-22 17:42:04 -05:00
|
|
|
return;
|
|
|
|
}
|
2018-03-19 22:29:58 +01:00
|
|
|
|
|
|
|
// If we're doing PGO generation stuff and on a GNU-like linker, use the
|
|
|
|
// "-u" flag to properly pull in the profiler runtime bits.
|
|
|
|
//
|
|
|
|
// This is because LLVM otherwise won't add the needed initialization
|
|
|
|
// for us on Linux (though the extra flag should be harmless if it
|
|
|
|
// does).
|
|
|
|
//
|
|
|
|
// See https://reviews.llvm.org/D14033 and https://reviews.llvm.org/D14030.
|
|
|
|
//
|
|
|
|
// Though it may be worth to try to revert those changes upstream, since
|
|
|
|
// the overhead of the initialization should be minor.
|
|
|
|
self.cmd.arg("-u");
|
|
|
|
self.cmd.arg("__llvm_profile_runtime");
|
|
|
|
}
|
|
|
|
|
2020-07-06 16:10:42 +01:00
|
|
|
fn control_flow_guard(&mut self) {}
|
2020-01-13 13:25:39 +00:00
|
|
|
|
2020-05-03 12:36:12 +08:00
|
|
|
fn debuginfo(&mut self, strip: Strip) {
|
|
|
|
match strip {
|
|
|
|
Strip::None => {}
|
|
|
|
Strip::Debuginfo => {
|
2020-06-08 17:24:21 +01:00
|
|
|
// MacOS linker does not support longhand argument --strip-debug
|
|
|
|
self.linker_arg("-S");
|
2018-10-06 11:49:03 +02:00
|
|
|
}
|
2020-05-03 12:36:12 +08:00
|
|
|
Strip::Symbols => {
|
2020-06-08 17:24:21 +01:00
|
|
|
// MacOS linker does not support longhand argument --strip-all
|
|
|
|
self.linker_arg("-s");
|
2020-05-03 12:36:12 +08:00
|
|
|
}
|
|
|
|
}
|
2015-07-04 23:25:38 +02:00
|
|
|
}
|
|
|
|
|
2020-04-29 20:47:07 +03:00
|
|
|
fn no_crt_objects(&mut self) {
|
|
|
|
if !self.is_ld {
|
|
|
|
self.cmd.arg("-nostartfiles");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-08 15:31:23 -07:00
|
|
|
fn no_default_libraries(&mut self) {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
if !self.is_ld {
|
|
|
|
self.cmd.arg("-nodefaultlibs");
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
|
2016-05-25 01:45:25 +03:00
|
|
|
fn export_symbols(&mut self, tmpdir: &Path, crate_type: CrateType) {
|
2019-05-03 13:59:50 -07:00
|
|
|
// Symbol visibility in object files typically takes care of this.
|
2020-11-08 14:27:51 +03:00
|
|
|
if crate_type == CrateType::Executable && self.sess.target.override_export_symbols.is_none()
|
2019-12-22 17:42:04 -05:00
|
|
|
{
|
2019-05-03 13:59:50 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-04-06 18:07:53 +02:00
|
|
|
// We manually create a list of exported symbols to ensure we don't expose any more.
|
|
|
|
// The object files have far more public symbols than we actually want to export,
|
|
|
|
// so we hide them all here.
|
2016-05-10 14:17:57 -07:00
|
|
|
|
2020-11-08 14:27:51 +03:00
|
|
|
if !self.sess.target.limit_rdylib_exports {
|
2019-03-19 13:06:37 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-04-14 19:05:21 +02:00
|
|
|
if crate_type == CrateType::ProcMacro {
|
2019-12-22 17:42:04 -05:00
|
|
|
return;
|
2019-03-19 13:06:37 -07:00
|
|
|
}
|
|
|
|
|
2020-11-08 14:27:51 +03:00
|
|
|
let is_windows = self.sess.target.is_like_windows;
|
2016-08-13 14:09:43 +05:00
|
|
|
let mut arg = OsString::new();
|
2020-05-07 11:52:21 +02:00
|
|
|
let path = tmpdir.join(if is_windows { "list.def" } else { "list" });
|
2016-08-13 14:09:43 +05:00
|
|
|
|
2016-12-01 14:57:46 -05:00
|
|
|
debug!("EXPORTED SYMBOLS:");
|
|
|
|
|
2020-11-08 14:27:51 +03:00
|
|
|
if self.sess.target.is_like_osx {
|
2016-11-30 13:16:53 -05:00
|
|
|
// Write a plain, newline-separated list of symbols
|
2019-03-14 23:12:56 +09:00
|
|
|
let res: io::Result<()> = try {
|
2016-08-13 14:09:43 +05:00
|
|
|
let mut f = BufWriter::new(File::create(&path)?);
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-22 17:07:11 -07:00
|
|
|
for sym in self.info.exports[&crate_type].iter() {
|
2016-12-01 14:57:46 -05:00
|
|
|
debug!(" _{}", sym);
|
2016-11-30 13:16:53 -05:00
|
|
|
writeln!(f, "_{}", sym)?;
|
2016-08-13 14:09:43 +05:00
|
|
|
}
|
2019-03-14 23:12:56 +09:00
|
|
|
};
|
2016-08-13 14:09:43 +05:00
|
|
|
if let Err(e) = res {
|
2016-11-30 13:16:53 -05:00
|
|
|
self.sess.fatal(&format!("failed to write lib.def file: {}", e));
|
2016-05-10 14:17:57 -07:00
|
|
|
}
|
2020-05-07 11:52:21 +02:00
|
|
|
} else if is_windows {
|
|
|
|
let res: io::Result<()> = try {
|
|
|
|
let mut f = BufWriter::new(File::create(&path)?);
|
|
|
|
|
|
|
|
// .def file similar to MSVC one but without LIBRARY section
|
|
|
|
// because LD doesn't like when it's empty
|
|
|
|
writeln!(f, "EXPORTS")?;
|
|
|
|
for symbol in self.info.exports[&crate_type].iter() {
|
|
|
|
debug!(" _{}", symbol);
|
|
|
|
writeln!(f, " {}", symbol)?;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
if let Err(e) = res {
|
|
|
|
self.sess.fatal(&format!("failed to write list.def file: {}", e));
|
|
|
|
}
|
2016-05-10 14:17:57 -07:00
|
|
|
} else {
|
2016-11-30 13:16:53 -05:00
|
|
|
// Write an LD version script
|
2019-03-14 23:12:56 +09:00
|
|
|
let res: io::Result<()> = try {
|
2016-08-13 14:09:43 +05:00
|
|
|
let mut f = BufWriter::new(File::create(&path)?);
|
2019-08-27 20:35:33 -04:00
|
|
|
writeln!(f, "{{")?;
|
|
|
|
if !self.info.exports[&crate_type].is_empty() {
|
|
|
|
writeln!(f, " global:")?;
|
|
|
|
for sym in self.info.exports[&crate_type].iter() {
|
|
|
|
debug!(" {};", sym);
|
|
|
|
writeln!(f, " {};", sym)?;
|
|
|
|
}
|
2016-08-13 14:09:43 +05:00
|
|
|
}
|
2016-11-30 13:16:53 -05:00
|
|
|
writeln!(f, "\n local:\n *;\n}};")?;
|
2019-03-14 23:12:56 +09:00
|
|
|
};
|
2016-08-13 14:09:43 +05:00
|
|
|
if let Err(e) = res {
|
2016-11-30 13:16:53 -05:00
|
|
|
self.sess.fatal(&format!("failed to write version script: {}", e));
|
2016-08-13 14:09:43 +05:00
|
|
|
}
|
2016-05-10 14:17:57 -07:00
|
|
|
}
|
2016-08-13 14:09:43 +05:00
|
|
|
|
2020-11-08 14:27:51 +03:00
|
|
|
if self.sess.target.is_like_osx {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
if !self.is_ld {
|
|
|
|
arg.push("-Wl,")
|
|
|
|
}
|
|
|
|
arg.push("-exported_symbols_list,");
|
2020-11-08 14:27:51 +03:00
|
|
|
} else if self.sess.target.is_like_solaris {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
if !self.is_ld {
|
|
|
|
arg.push("-Wl,")
|
|
|
|
}
|
|
|
|
arg.push("-M,");
|
2016-11-30 13:16:53 -05:00
|
|
|
} else {
|
-Z linker-flavor
This patch adds a `-Z linker-flavor` flag to rustc which can be used to invoke
the linker using a different interface.
For example, by default rustc assumes that all the Linux targets will be linked
using GCC. This makes it impossible to use LLD as a linker using just `-C
linker=ld.lld` because that will invoke LLD with invalid command line
arguments. (e.g. rustc will pass -Wl,--gc-sections to LLD but LLD doesn't
understand that; --gc-sections would be the right argument)
With this patch one can pass `-Z linker-flavor=ld` to rustc to invoke the linker
using a LD-like interface. This way, `rustc -C linker=ld.lld -Z
linker-flavor=ld` will invoke LLD with the right arguments.
`-Z linker-flavor` accepts 4 different arguments: `em` (emcc), `ld`,
`gcc`, `msvc` (link.exe). `em`, `gnu` and `msvc` cover all the existing linker
interfaces. `ld` is a new flavor for interfacing GNU's ld and LLD.
This patch also changes target specifications. `linker-flavor` is now a
mandatory field that specifies the *default* linker flavor that the target will
use. This change also makes the linker interface *explicit*; before, it used to
be derived from other fields like linker-is-gnu, is-like-msvc,
is-like-emscripten, etc.
Another change to target specifications is that the fields `pre-link-args`,
`post-link-args` and `late-link-args` now expect a map from flavor to linker
arguments.
``` diff
- "pre-link-args": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "pre-link-args": {
+ "gcc": ["-Wl,--as-needed", "-Wl,-z,-noexecstack"],
+ "ld": ["--as-needed", "-z,-noexecstack"],
+ },
```
[breaking-change] for users of custom targets specifications
2017-02-21 14:47:15 -05:00
|
|
|
if !self.is_ld {
|
|
|
|
arg.push("-Wl,")
|
|
|
|
}
|
2020-05-07 11:52:21 +02:00
|
|
|
// Both LD and LLD accept export list in *.def file form, there are no flags required
|
|
|
|
if !is_windows {
|
|
|
|
arg.push("--version-script=")
|
|
|
|
}
|
2016-11-30 13:16:53 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
arg.push(&path);
|
2016-05-10 14:17:57 -07:00
|
|
|
self.cmd.arg(arg);
|
2015-07-28 17:19:08 -07:00
|
|
|
}
|
2016-10-31 09:36:30 -07:00
|
|
|
|
|
|
|
fn subsystem(&mut self, subsystem: &str) {
|
2018-07-24 02:11:57 +01:00
|
|
|
self.linker_arg("--subsystem");
|
|
|
|
self.linker_arg(&subsystem);
|
2016-10-31 09:36:30 -07:00
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
|
2020-04-05 02:58:32 +03:00
|
|
|
fn finalize(&mut self) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_dynamic(); // Reset to default before returning the composed command line.
|
|
|
|
}
|
2018-03-23 14:33:22 -07:00
|
|
|
|
|
|
|
fn group_start(&mut self) {
|
2019-03-19 13:06:37 -07:00
|
|
|
if self.takes_hints() {
|
2018-03-23 14:33:22 -07:00
|
|
|
self.linker_arg("--start-group");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn group_end(&mut self) {
|
2019-03-19 13:06:37 -07:00
|
|
|
if self.takes_hints() {
|
2018-03-23 14:33:22 -07:00
|
|
|
self.linker_arg("--end-group");
|
|
|
|
}
|
|
|
|
}
|
2018-04-25 15:45:04 +02:00
|
|
|
|
2019-02-01 15:15:43 +01:00
|
|
|
fn linker_plugin_lto(&mut self) {
|
|
|
|
match self.sess.opts.cg.linker_plugin_lto {
|
|
|
|
LinkerPluginLto::Disabled => {
|
2018-04-25 15:45:04 +02:00
|
|
|
// Nothing to do
|
|
|
|
}
|
2019-02-01 15:15:43 +01:00
|
|
|
LinkerPluginLto::LinkerPluginAuto => {
|
|
|
|
self.push_linker_plugin_lto_args(None);
|
2018-07-03 16:33:11 +02:00
|
|
|
}
|
2019-02-01 15:15:43 +01:00
|
|
|
LinkerPluginLto::LinkerPlugin(ref path) => {
|
|
|
|
self.push_linker_plugin_lto_args(Some(path.as_os_str()));
|
2018-04-25 15:45:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-06-20 23:26:24 +03:00
|
|
|
|
|
|
|
// Add the `GNU_EH_FRAME` program header which is required to locate unwinding information.
|
|
|
|
// Some versions of `gcc` add it implicitly, some (e.g. `musl-gcc`) don't,
|
|
|
|
// so we just always add it.
|
|
|
|
fn add_eh_frame_header(&mut self) {
|
2020-07-22 15:49:04 +03:00
|
|
|
self.linker_arg("--eh-frame-hdr");
|
2020-06-20 23:26:24 +03:00
|
|
|
}
|
2021-03-28 00:02:23 +03:00
|
|
|
|
|
|
|
fn add_as_needed(&mut self) {
|
|
|
|
if self.sess.target.linker_is_gnu {
|
|
|
|
self.linker_arg("--as-needed");
|
|
|
|
}
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
2015-05-11 14:57:21 -07:00
|
|
|
|
|
|
|
pub struct MsvcLinker<'a> {
|
2017-03-23 18:03:39 -07:00
|
|
|
cmd: Command,
|
2016-05-25 01:45:25 +03:00
|
|
|
sess: &'a Session,
|
2019-12-22 17:42:04 -05:00
|
|
|
info: &'a LinkerInfo,
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Linker for MsvcLinker<'a> {
|
2020-04-05 02:11:29 +03:00
|
|
|
fn cmd(&mut self) -> &mut Command {
|
|
|
|
&mut self.cmd
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
|
|
|
|
fn set_output_kind(&mut self, output_kind: LinkOutputKind, out_filename: &Path) {
|
|
|
|
match output_kind {
|
|
|
|
LinkOutputKind::DynamicNoPicExe
|
|
|
|
| LinkOutputKind::DynamicPicExe
|
|
|
|
| LinkOutputKind::StaticNoPicExe
|
|
|
|
| LinkOutputKind::StaticPicExe => {}
|
|
|
|
LinkOutputKind::DynamicDylib | LinkOutputKind::StaticDylib => {
|
|
|
|
self.cmd.arg("/DLL");
|
|
|
|
let mut arg: OsString = "/IMPLIB:".into();
|
|
|
|
arg.push(out_filename.with_extension("dll.lib"));
|
|
|
|
self.cmd.arg(arg);
|
|
|
|
}
|
2020-12-12 21:38:23 -06:00
|
|
|
LinkOutputKind::WasiReactorExe => {
|
|
|
|
panic!("can't link as reactor on non-wasi target");
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn link_rlib(&mut self, lib: &Path) {
|
|
|
|
self.cmd.arg(lib);
|
|
|
|
}
|
|
|
|
fn add_object(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg(path);
|
|
|
|
}
|
2015-12-04 22:36:01 -05:00
|
|
|
|
2016-05-10 14:17:57 -07:00
|
|
|
fn gc_sections(&mut self, _keep_metadata: bool) {
|
2016-11-25 19:17:21 +11:00
|
|
|
// MSVC's ICF (Identical COMDAT Folding) link optimization is
|
|
|
|
// slow for Rust and thus we disable it by default when not in
|
|
|
|
// optimization build.
|
|
|
|
if self.sess.opts.optimize != config::OptLevel::No {
|
|
|
|
self.cmd.arg("/OPT:REF,ICF");
|
|
|
|
} else {
|
|
|
|
// It is necessary to specify NOICF here, because /OPT:REF
|
|
|
|
// implies ICF by default.
|
|
|
|
self.cmd.arg("/OPT:REF,NOICF");
|
|
|
|
}
|
2016-05-10 14:17:57 -07:00
|
|
|
}
|
2015-05-11 14:57:21 -07:00
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_dylib(&mut self, lib: Symbol) {
|
2015-05-11 14:57:21 -07:00
|
|
|
self.cmd.arg(&format!("{}.lib", lib));
|
|
|
|
}
|
2015-06-25 00:33:52 -07:00
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_rust_dylib(&mut self, lib: Symbol, path: &Path) {
|
2015-06-25 00:33:52 -07:00
|
|
|
// When producing a dll, the MSVC linker may not actually emit a
|
|
|
|
// `foo.lib` file if the dll doesn't actually export any symbols, so we
|
|
|
|
// check to see if the file is there and just omit linking to it if it's
|
|
|
|
// not present.
|
2015-12-04 22:36:01 -05:00
|
|
|
let name = format!("{}.dll.lib", lib);
|
2015-06-25 00:33:52 -07:00
|
|
|
if fs::metadata(&path.join(&name)).is_ok() {
|
|
|
|
self.cmd.arg(name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_staticlib(&mut self, lib: Symbol) {
|
2015-05-11 14:57:21 -07:00
|
|
|
self.cmd.arg(&format!("{}.lib", lib));
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:28:20 +01:00
|
|
|
fn full_relro(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2017-07-14 22:01:37 +02:00
|
|
|
fn partial_relro(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:28:20 +01:00
|
|
|
fn no_relro(&mut self) {
|
2017-07-10 20:57:45 +02:00
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2020-04-29 20:47:07 +03:00
|
|
|
fn no_crt_objects(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2015-05-11 14:57:21 -07:00
|
|
|
fn no_default_libraries(&mut self) {
|
2020-04-11 14:53:39 +03:00
|
|
|
self.cmd.arg("/NODEFAULTLIB");
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
fn include_path(&mut self, path: &Path) {
|
|
|
|
let mut arg = OsString::from("/LIBPATH:");
|
|
|
|
arg.push(path);
|
|
|
|
self.cmd.arg(&arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn output_filename(&mut self, path: &Path) {
|
|
|
|
let mut arg = OsString::from("/OUT:");
|
|
|
|
arg.push(path);
|
|
|
|
self.cmd.arg(&arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn framework_path(&mut self, _path: &Path) {
|
2016-03-29 01:46:02 +02:00
|
|
|
bug!("frameworks are not supported on windows")
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_framework(&mut self, _framework: Symbol) {
|
2016-03-29 01:46:02 +02:00
|
|
|
bug!("frameworks are not supported on windows")
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_whole_staticlib(&mut self, lib: Symbol, _search_path: &[PathBuf]) {
|
2015-05-11 14:57:21 -07:00
|
|
|
self.link_staticlib(lib);
|
2020-05-30 18:46:52 +03:00
|
|
|
self.cmd.arg(format!("/WHOLEARCHIVE:{}.lib", lib));
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
2015-07-07 21:33:44 -07:00
|
|
|
fn link_whole_rlib(&mut self, path: &Path) {
|
|
|
|
self.link_rlib(path);
|
2020-05-30 18:46:52 +03:00
|
|
|
let mut arg = OsString::from("/WHOLEARCHIVE:");
|
|
|
|
arg.push(path);
|
|
|
|
self.cmd.arg(arg);
|
2015-07-07 21:33:44 -07:00
|
|
|
}
|
2015-05-11 14:57:21 -07:00
|
|
|
fn optimize(&mut self) {
|
|
|
|
// Needs more investigation of `/OPT` arguments
|
|
|
|
}
|
2015-07-04 23:25:38 +02:00
|
|
|
|
2018-03-19 22:29:58 +01:00
|
|
|
fn pgo_gen(&mut self) {
|
|
|
|
// Nothing needed here.
|
|
|
|
}
|
|
|
|
|
2020-01-13 13:25:39 +00:00
|
|
|
fn control_flow_guard(&mut self) {
|
|
|
|
self.cmd.arg("/guard:cf");
|
|
|
|
}
|
|
|
|
|
2020-05-03 12:36:12 +08:00
|
|
|
fn debuginfo(&mut self, strip: Strip) {
|
|
|
|
match strip {
|
|
|
|
Strip::None => {
|
|
|
|
// This will cause the Microsoft linker to generate a PDB file
|
|
|
|
// from the CodeView line tables in the object files.
|
|
|
|
self.cmd.arg("/DEBUG");
|
|
|
|
|
|
|
|
// This will cause the Microsoft linker to embed .natvis info into the PDB file
|
|
|
|
let natvis_dir_path = self.sess.sysroot.join("lib\\rustlib\\etc");
|
|
|
|
if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {
|
|
|
|
for entry in natvis_dir {
|
|
|
|
match entry {
|
|
|
|
Ok(entry) => {
|
|
|
|
let path = entry.path();
|
|
|
|
if path.extension() == Some("natvis".as_ref()) {
|
|
|
|
let mut arg = OsString::from("/NATVIS:");
|
|
|
|
arg.push(path);
|
|
|
|
self.cmd.arg(arg);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Err(err) => {
|
|
|
|
self.sess
|
|
|
|
.warn(&format!("error enumerating natvis directory: {}", err));
|
|
|
|
}
|
2017-07-13 10:03:07 -07:00
|
|
|
}
|
2019-12-22 17:42:04 -05:00
|
|
|
}
|
2017-07-13 10:03:07 -07:00
|
|
|
}
|
|
|
|
}
|
2020-05-03 12:36:12 +08:00
|
|
|
Strip::Debuginfo | Strip::Symbols => {
|
|
|
|
self.cmd.arg("/DEBUG:NONE");
|
|
|
|
}
|
2017-07-13 10:03:07 -07:00
|
|
|
}
|
2015-07-04 23:25:38 +02:00
|
|
|
}
|
|
|
|
|
2015-07-28 17:19:08 -07:00
|
|
|
// Currently the compiler doesn't use `dllexport` (an LLVM attribute) to
|
|
|
|
// export symbols from a dynamic library. When building a dynamic library,
|
|
|
|
// however, we're going to want some symbols exported, so this function
|
|
|
|
// generates a DEF file which lists all the symbols.
|
|
|
|
//
|
|
|
|
// The linker will read this `*.def` file and export all the symbols from
|
|
|
|
// the dynamic library. Note that this is not as simple as just exporting
|
2018-05-08 16:10:16 +03:00
|
|
|
// all the symbols in the current crate (as specified by `codegen.reachable`)
|
2015-07-28 17:19:08 -07:00
|
|
|
// but rather we also need to possibly export the symbols of upstream
|
|
|
|
// crates. Upstream rlibs may be linked statically to this dynamic library,
|
|
|
|
// in which case they may continue to transitively be used and hence need
|
|
|
|
// their symbols exported.
|
2019-12-22 17:42:04 -05:00
|
|
|
fn export_symbols(&mut self, tmpdir: &Path, crate_type: CrateType) {
|
2019-05-03 13:59:50 -07:00
|
|
|
// Symbol visibility takes care of this typically
|
|
|
|
if crate_type == CrateType::Executable {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-07-28 17:19:08 -07:00
|
|
|
let path = tmpdir.join("lib.def");
|
2019-03-14 23:12:56 +09:00
|
|
|
let res: io::Result<()> = try {
|
2016-03-22 22:01:37 -05:00
|
|
|
let mut f = BufWriter::new(File::create(&path)?);
|
2015-07-28 17:19:08 -07:00
|
|
|
|
|
|
|
// Start off with the standard module name header and then go
|
|
|
|
// straight to exports.
|
2016-03-22 22:01:37 -05:00
|
|
|
writeln!(f, "LIBRARY")?;
|
|
|
|
writeln!(f, "EXPORTS")?;
|
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
2016-08-22 17:07:11 -07:00
|
|
|
for symbol in self.info.exports[&crate_type].iter() {
|
2017-02-03 18:25:20 -08:00
|
|
|
debug!(" _{}", symbol);
|
2016-05-25 01:45:25 +03:00
|
|
|
writeln!(f, " {}", symbol)?;
|
2015-07-28 17:19:08 -07:00
|
|
|
}
|
2019-03-14 23:12:56 +09:00
|
|
|
};
|
2015-07-28 17:19:08 -07:00
|
|
|
if let Err(e) = res {
|
2016-05-25 01:45:25 +03:00
|
|
|
self.sess.fatal(&format!("failed to write lib.def file: {}", e));
|
2015-07-28 17:19:08 -07:00
|
|
|
}
|
|
|
|
let mut arg = OsString::from("/DEF:");
|
|
|
|
arg.push(path);
|
|
|
|
self.cmd.arg(&arg);
|
|
|
|
}
|
2016-10-31 09:36:30 -07:00
|
|
|
|
|
|
|
fn subsystem(&mut self, subsystem: &str) {
|
|
|
|
// Note that previous passes of the compiler validated this subsystem,
|
|
|
|
// so we just blindly pass it to the linker.
|
|
|
|
self.cmd.arg(&format!("/SUBSYSTEM:{}", subsystem));
|
|
|
|
|
|
|
|
// Windows has two subsystems we're interested in right now, the console
|
|
|
|
// and windows subsystems. These both implicitly have different entry
|
|
|
|
// points (starting symbols). The console entry point starts with
|
|
|
|
// `mainCRTStartup` and the windows entry point starts with
|
|
|
|
// `WinMainCRTStartup`. These entry points, defined in system libraries,
|
|
|
|
// will then later probe for either `main` or `WinMain`, respectively to
|
|
|
|
// start the application.
|
|
|
|
//
|
|
|
|
// In Rust we just always generate a `main` function so we want control
|
|
|
|
// to always start there, so we force the entry point on the windows
|
|
|
|
// subsystem to be `mainCRTStartup` to get everything booted up
|
|
|
|
// correctly.
|
|
|
|
//
|
|
|
|
// For more information see RFC #1665
|
|
|
|
if subsystem == "windows" {
|
|
|
|
self.cmd.arg("/ENTRY:mainCRTStartup");
|
|
|
|
}
|
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
|
2020-04-05 02:58:32 +03:00
|
|
|
fn finalize(&mut self) {}
|
2018-03-23 14:33:22 -07:00
|
|
|
|
|
|
|
// MSVC doesn't need group indicators
|
|
|
|
fn group_start(&mut self) {}
|
|
|
|
fn group_end(&mut self) {}
|
2018-04-25 15:45:04 +02:00
|
|
|
|
2019-02-01 15:15:43 +01:00
|
|
|
fn linker_plugin_lto(&mut self) {
|
2018-04-25 15:45:04 +02:00
|
|
|
// Do nothing
|
|
|
|
}
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
2016-05-10 14:17:57 -07:00
|
|
|
|
2017-02-03 14:58:13 +00:00
|
|
|
pub struct EmLinker<'a> {
|
2017-03-23 18:03:39 -07:00
|
|
|
cmd: Command,
|
2017-02-03 14:58:13 +00:00
|
|
|
sess: &'a Session,
|
2019-12-22 17:42:04 -05:00
|
|
|
info: &'a LinkerInfo,
|
2017-02-03 14:58:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Linker for EmLinker<'a> {
|
2020-04-05 02:11:29 +03:00
|
|
|
fn cmd(&mut self) -> &mut Command {
|
|
|
|
&mut self.cmd
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
|
|
|
|
fn set_output_kind(&mut self, _output_kind: LinkOutputKind, _out_filename: &Path) {}
|
|
|
|
|
2017-02-03 14:58:13 +00:00
|
|
|
fn include_path(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-L").arg(path);
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_staticlib(&mut self, lib: Symbol) {
|
|
|
|
self.cmd.arg("-l").sym_arg(lib);
|
2017-02-03 14:58:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fn output_filename(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-o").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn add_object(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg(path);
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_dylib(&mut self, lib: Symbol) {
|
2017-02-03 14:58:13 +00:00
|
|
|
// Emscripten always links statically
|
|
|
|
self.link_staticlib(lib);
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_whole_staticlib(&mut self, lib: Symbol, _search_path: &[PathBuf]) {
|
2017-02-03 14:58:13 +00:00
|
|
|
// not supported?
|
|
|
|
self.link_staticlib(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_rlib(&mut self, lib: &Path) {
|
|
|
|
// not supported?
|
|
|
|
self.link_rlib(lib);
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_rust_dylib(&mut self, lib: Symbol, _path: &Path) {
|
2017-02-03 14:58:13 +00:00
|
|
|
self.link_dylib(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_rlib(&mut self, lib: &Path) {
|
|
|
|
self.add_object(lib);
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:28:20 +01:00
|
|
|
fn full_relro(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2017-07-14 22:01:37 +02:00
|
|
|
fn partial_relro(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:28:20 +01:00
|
|
|
fn no_relro(&mut self) {
|
2017-07-10 20:57:45 +02:00
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2017-02-03 14:58:13 +00:00
|
|
|
fn framework_path(&mut self, _path: &Path) {
|
|
|
|
bug!("frameworks are not supported on Emscripten")
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_framework(&mut self, _framework: Symbol) {
|
2017-02-03 14:58:13 +00:00
|
|
|
bug!("frameworks are not supported on Emscripten")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn gc_sections(&mut self, _keep_metadata: bool) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
|
|
|
fn optimize(&mut self) {
|
|
|
|
// Emscripten performs own optimizations
|
|
|
|
self.cmd.arg(match self.sess.opts.optimize {
|
|
|
|
OptLevel::No => "-O0",
|
|
|
|
OptLevel::Less => "-O1",
|
|
|
|
OptLevel::Default => "-O2",
|
|
|
|
OptLevel::Aggressive => "-O3",
|
|
|
|
OptLevel::Size => "-Os",
|
2019-12-22 17:42:04 -05:00
|
|
|
OptLevel::SizeMin => "-Oz",
|
2017-02-03 14:58:13 +00:00
|
|
|
});
|
2017-02-10 17:12:18 +00:00
|
|
|
// Unusable until https://github.com/rust-lang/rust/issues/38454 is resolved
|
|
|
|
self.cmd.args(&["--memory-init-file", "0"]);
|
2017-02-03 14:58:13 +00:00
|
|
|
}
|
|
|
|
|
2018-03-19 22:29:58 +01:00
|
|
|
fn pgo_gen(&mut self) {
|
|
|
|
// noop, but maybe we need something like the gnu linker?
|
|
|
|
}
|
|
|
|
|
2020-07-06 16:10:42 +01:00
|
|
|
fn control_flow_guard(&mut self) {}
|
2020-01-13 13:25:39 +00:00
|
|
|
|
2020-05-03 12:36:12 +08:00
|
|
|
fn debuginfo(&mut self, _strip: Strip) {
|
2017-02-03 14:58:13 +00:00
|
|
|
// Preserve names or generate source maps depending on debug info
|
|
|
|
self.cmd.arg(match self.sess.opts.debuginfo {
|
2018-07-26 11:41:10 -06:00
|
|
|
DebugInfo::None => "-g0",
|
|
|
|
DebugInfo::Limited => "-g3",
|
2019-12-22 17:42:04 -05:00
|
|
|
DebugInfo::Full => "-g4",
|
2017-02-03 14:58:13 +00:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-04-29 20:47:07 +03:00
|
|
|
fn no_crt_objects(&mut self) {}
|
|
|
|
|
2017-02-03 14:58:13 +00:00
|
|
|
fn no_default_libraries(&mut self) {
|
|
|
|
self.cmd.args(&["-s", "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]"]);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn export_symbols(&mut self, _tmpdir: &Path, crate_type: CrateType) {
|
|
|
|
let symbols = &self.info.exports[&crate_type];
|
|
|
|
|
|
|
|
debug!("EXPORTED SYMBOLS:");
|
|
|
|
|
|
|
|
self.cmd.arg("-s");
|
|
|
|
|
|
|
|
let mut arg = OsString::from("EXPORTED_FUNCTIONS=");
|
|
|
|
let mut encoded = String::new();
|
|
|
|
|
|
|
|
{
|
|
|
|
let mut encoder = json::Encoder::new(&mut encoded);
|
|
|
|
let res = encoder.emit_seq(symbols.len(), |encoder| {
|
|
|
|
for (i, sym) in symbols.iter().enumerate() {
|
2019-12-22 17:42:04 -05:00
|
|
|
encoder.emit_seq_elt(i, |encoder| encoder.emit_str(&("_".to_owned() + sym)))?;
|
2017-02-03 14:58:13 +00:00
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
});
|
|
|
|
if let Err(e) = res {
|
|
|
|
self.sess.fatal(&format!("failed to encode exported symbols: {}", e));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
debug!("{}", encoded);
|
|
|
|
arg.push(encoded);
|
|
|
|
|
|
|
|
self.cmd.arg(arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn subsystem(&mut self, _subsystem: &str) {
|
|
|
|
// noop
|
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
|
2020-04-05 02:58:32 +03:00
|
|
|
fn finalize(&mut self) {}
|
2018-03-23 14:33:22 -07:00
|
|
|
|
|
|
|
// Appears not necessary on Emscripten
|
|
|
|
fn group_start(&mut self) {}
|
|
|
|
fn group_end(&mut self) {}
|
2018-04-25 15:45:04 +02:00
|
|
|
|
2019-02-01 15:15:43 +01:00
|
|
|
fn linker_plugin_lto(&mut self) {
|
2018-04-25 15:45:04 +02:00
|
|
|
// Do nothing
|
|
|
|
}
|
2017-02-03 14:58:13 +00:00
|
|
|
}
|
|
|
|
|
2018-06-01 10:20:00 -07:00
|
|
|
pub struct WasmLd<'a> {
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
cmd: Command,
|
2018-06-01 10:20:00 -07:00
|
|
|
sess: &'a Session,
|
2018-10-02 13:49:51 -07:00
|
|
|
info: &'a LinkerInfo,
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
2019-01-04 07:54:33 -08:00
|
|
|
impl<'a> WasmLd<'a> {
|
2019-07-19 07:08:37 -07:00
|
|
|
fn new(mut cmd: Command, sess: &'a Session, info: &'a LinkerInfo) -> WasmLd<'a> {
|
|
|
|
// If the atomics feature is enabled for wasm then we need a whole bunch
|
|
|
|
// of flags:
|
|
|
|
//
|
|
|
|
// * `--shared-memory` - the link won't even succeed without this, flags
|
|
|
|
// the one linear memory as `shared`
|
|
|
|
//
|
|
|
|
// * `--max-memory=1G` - when specifying a shared memory this must also
|
|
|
|
// be specified. We conservatively choose 1GB but users should be able
|
|
|
|
// to override this with `-C link-arg`.
|
|
|
|
//
|
|
|
|
// * `--import-memory` - it doesn't make much sense for memory to be
|
|
|
|
// exported in a threaded module because typically you're
|
|
|
|
// sharing memory and instantiating the module multiple times. As a
|
|
|
|
// result if it were exported then we'd just have no sharing.
|
|
|
|
//
|
|
|
|
// * `--export=__wasm_init_memory` - when using `--passive-segments` the
|
|
|
|
// linker will synthesize this function, and so we need to make sure
|
|
|
|
// that our usage of `--export` below won't accidentally cause this
|
|
|
|
// function to get deleted.
|
2019-07-19 12:02:34 -07:00
|
|
|
//
|
|
|
|
// * `--export=*tls*` - when `#[thread_local]` symbols are used these
|
|
|
|
// symbols are how the TLS segments are initialized and configured.
|
2020-06-23 09:41:56 -07:00
|
|
|
if sess.target_features.contains(&sym::atomics) {
|
2019-07-19 07:08:37 -07:00
|
|
|
cmd.arg("--shared-memory");
|
|
|
|
cmd.arg("--max-memory=1073741824");
|
|
|
|
cmd.arg("--import-memory");
|
|
|
|
cmd.arg("--export=__wasm_init_memory");
|
2019-07-19 12:02:34 -07:00
|
|
|
cmd.arg("--export=__wasm_init_tls");
|
|
|
|
cmd.arg("--export=__tls_size");
|
|
|
|
cmd.arg("--export=__tls_align");
|
|
|
|
cmd.arg("--export=__tls_base");
|
2019-07-19 07:08:37 -07:00
|
|
|
}
|
2019-01-04 07:54:33 -08:00
|
|
|
WasmLd { cmd, sess, info }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-01 10:20:00 -07:00
|
|
|
impl<'a> Linker for WasmLd<'a> {
|
2020-04-05 02:11:29 +03:00
|
|
|
fn cmd(&mut self) -> &mut Command {
|
|
|
|
&mut self.cmd
|
|
|
|
}
|
|
|
|
|
2020-05-02 02:22:48 +03:00
|
|
|
fn set_output_kind(&mut self, output_kind: LinkOutputKind, _out_filename: &Path) {
|
|
|
|
match output_kind {
|
|
|
|
LinkOutputKind::DynamicNoPicExe
|
|
|
|
| LinkOutputKind::DynamicPicExe
|
|
|
|
| LinkOutputKind::StaticNoPicExe
|
|
|
|
| LinkOutputKind::StaticPicExe => {}
|
|
|
|
LinkOutputKind::DynamicDylib | LinkOutputKind::StaticDylib => {
|
|
|
|
self.cmd.arg("--no-entry");
|
|
|
|
}
|
2020-12-12 21:38:23 -06:00
|
|
|
LinkOutputKind::WasiReactorExe => {
|
|
|
|
self.cmd.arg("--entry");
|
|
|
|
self.cmd.arg("_initialize");
|
|
|
|
}
|
2020-05-02 02:22:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_dylib(&mut self, lib: Symbol) {
|
|
|
|
self.cmd.arg("-l").sym_arg(lib);
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_staticlib(&mut self, lib: Symbol) {
|
|
|
|
self.cmd.arg("-l").sym_arg(lib);
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
fn link_rlib(&mut self, lib: &Path) {
|
|
|
|
self.cmd.arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn include_path(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-L").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn framework_path(&mut self, _path: &Path) {
|
|
|
|
panic!("frameworks not supported")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn output_filename(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-o").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn add_object(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg(path);
|
|
|
|
}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn full_relro(&mut self) {}
|
2018-02-22 21:28:20 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn partial_relro(&mut self) {}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn no_relro(&mut self) {}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_rust_dylib(&mut self, lib: Symbol, _path: &Path) {
|
|
|
|
self.cmd.arg("-l").sym_arg(lib);
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_framework(&mut self, _framework: Symbol) {
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
panic!("frameworks not supported")
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_whole_staticlib(&mut self, lib: Symbol, _search_path: &[PathBuf]) {
|
|
|
|
self.cmd.arg("-l").sym_arg(lib);
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_rlib(&mut self, lib: &Path) {
|
|
|
|
self.cmd.arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn gc_sections(&mut self, _keep_metadata: bool) {
|
2018-06-01 10:20:00 -07:00
|
|
|
self.cmd.arg("--gc-sections");
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
fn optimize(&mut self) {
|
2018-06-01 10:20:00 -07:00
|
|
|
self.cmd.arg(match self.sess.opts.optimize {
|
|
|
|
OptLevel::No => "-O0",
|
|
|
|
OptLevel::Less => "-O1",
|
|
|
|
OptLevel::Default => "-O2",
|
|
|
|
OptLevel::Aggressive => "-O3",
|
|
|
|
// Currently LLD doesn't support `Os` and `Oz`, so pass through `O2`
|
|
|
|
// instead.
|
|
|
|
OptLevel::Size => "-O2",
|
2019-12-22 17:42:04 -05:00
|
|
|
OptLevel::SizeMin => "-O2",
|
2018-06-01 10:20:00 -07:00
|
|
|
});
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn pgo_gen(&mut self) {}
|
2018-03-19 22:29:58 +01:00
|
|
|
|
2020-05-03 12:36:12 +08:00
|
|
|
fn debuginfo(&mut self, strip: Strip) {
|
|
|
|
match strip {
|
|
|
|
Strip::None => {}
|
|
|
|
Strip::Debuginfo => {
|
|
|
|
self.cmd.arg("--strip-debug");
|
|
|
|
}
|
|
|
|
Strip::Symbols => {
|
|
|
|
self.cmd.arg("--strip-all");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
2020-07-06 16:10:42 +01:00
|
|
|
fn control_flow_guard(&mut self) {}
|
2020-01-13 13:25:39 +00:00
|
|
|
|
2020-04-29 20:47:07 +03:00
|
|
|
fn no_crt_objects(&mut self) {}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn no_default_libraries(&mut self) {}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
2018-10-02 13:49:51 -07:00
|
|
|
fn export_symbols(&mut self, _tmpdir: &Path, crate_type: CrateType) {
|
|
|
|
for sym in self.info.exports[&crate_type].iter() {
|
|
|
|
self.cmd.arg("--export").arg(&sym);
|
|
|
|
}
|
2019-07-19 07:08:37 -07:00
|
|
|
|
2020-07-07 11:12:44 -04:00
|
|
|
// LLD will hide these otherwise-internal symbols since it only exports
|
|
|
|
// symbols explicity passed via the `--export` flags above and hides all
|
|
|
|
// others. Various bits and pieces of tooling use this, so be sure these
|
|
|
|
// symbols make their way out of the linker as well.
|
2019-07-19 07:08:37 -07:00
|
|
|
self.cmd.arg("--export=__heap_base");
|
|
|
|
self.cmd.arg("--export=__data_end");
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn subsystem(&mut self, _subsystem: &str) {}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
|
2020-04-05 02:58:32 +03:00
|
|
|
fn finalize(&mut self) {}
|
2018-03-23 14:33:22 -07:00
|
|
|
|
|
|
|
// Not needed for now with LLD
|
|
|
|
fn group_start(&mut self) {}
|
|
|
|
fn group_end(&mut self) {}
|
2018-04-25 15:45:04 +02:00
|
|
|
|
2019-02-01 15:15:43 +01:00
|
|
|
fn linker_plugin_lto(&mut self) {
|
2018-04-25 15:45:04 +02:00
|
|
|
// Do nothing for now
|
|
|
|
}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
|
|
|
}
|
2018-10-23 17:01:35 +02:00
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
fn exported_symbols(tcx: TyCtxt<'_>, crate_type: CrateType) -> Vec<String> {
|
2020-11-08 14:27:51 +03:00
|
|
|
if let Some(ref exports) = tcx.sess.target.override_export_symbols {
|
2019-12-22 17:42:04 -05:00
|
|
|
return exports.clone();
|
2018-11-19 15:04:28 +05:30
|
|
|
}
|
|
|
|
|
2018-10-23 17:01:35 +02:00
|
|
|
let mut symbols = Vec::new();
|
|
|
|
|
|
|
|
let export_threshold = symbol_export::crates_export_threshold(&[crate_type]);
|
|
|
|
for &(symbol, level) in tcx.exported_symbols(LOCAL_CRATE).iter() {
|
|
|
|
if level.is_below_threshold(export_threshold) {
|
2020-01-16 13:21:10 +01:00
|
|
|
symbols.push(symbol_export::symbol_name_for_instance_in_crate(
|
|
|
|
tcx,
|
|
|
|
symbol,
|
|
|
|
LOCAL_CRATE,
|
|
|
|
));
|
2018-10-23 17:01:35 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-09-16 13:34:57 -07:00
|
|
|
let formats = tcx.dependency_formats(LOCAL_CRATE);
|
2020-04-24 20:03:45 -07:00
|
|
|
let deps = formats.iter().find_map(|(t, list)| (*t == crate_type).then_some(list)).unwrap();
|
2018-10-23 17:01:35 +02:00
|
|
|
|
2019-09-16 13:34:57 -07:00
|
|
|
for (index, dep_format) in deps.iter().enumerate() {
|
2018-10-23 17:01:35 +02:00
|
|
|
let cnum = CrateNum::new(index + 1);
|
|
|
|
// For each dependency that we are linking to statically ...
|
|
|
|
if *dep_format == Linkage::Static {
|
|
|
|
// ... we add its symbol list to our export list.
|
|
|
|
for &(symbol, level) in tcx.exported_symbols(cnum).iter() {
|
2019-09-23 14:01:06 -07:00
|
|
|
if !level.is_below_threshold(export_threshold) {
|
|
|
|
continue;
|
2018-10-23 17:01:35 +02:00
|
|
|
}
|
2019-09-23 14:01:06 -07:00
|
|
|
|
2020-01-16 13:21:10 +01:00
|
|
|
symbols.push(symbol_export::symbol_name_for_instance_in_crate(tcx, symbol, cnum));
|
2018-10-23 17:01:35 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
symbols
|
|
|
|
}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
|
|
|
/// Much simplified and explicit CLI for the NVPTX linker. The linker operates
|
|
|
|
/// with bitcode and uses LLVM backend to generate a PTX assembly.
|
|
|
|
pub struct PtxLinker<'a> {
|
|
|
|
cmd: Command,
|
|
|
|
sess: &'a Session,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Linker for PtxLinker<'a> {
|
2020-04-05 02:11:29 +03:00
|
|
|
fn cmd(&mut self) -> &mut Command {
|
|
|
|
&mut self.cmd
|
|
|
|
}
|
|
|
|
|
2020-05-02 02:22:48 +03:00
|
|
|
fn set_output_kind(&mut self, _output_kind: LinkOutputKind, _out_filename: &Path) {}
|
|
|
|
|
2019-01-19 21:59:34 +01:00
|
|
|
fn link_rlib(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("--rlib").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_rlib(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("--rlib").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn include_path(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-L").arg(path);
|
|
|
|
}
|
|
|
|
|
2020-05-03 12:36:12 +08:00
|
|
|
fn debuginfo(&mut self, _strip: Strip) {
|
2019-01-19 21:59:34 +01:00
|
|
|
self.cmd.arg("--debug");
|
|
|
|
}
|
|
|
|
|
|
|
|
fn add_object(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("--bitcode").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn optimize(&mut self) {
|
2019-01-28 23:56:37 +01:00
|
|
|
match self.sess.lto() {
|
|
|
|
Lto::Thin | Lto::Fat | Lto::ThinLocal => {
|
|
|
|
self.cmd.arg("-Olto");
|
2019-12-22 17:42:04 -05:00
|
|
|
}
|
2019-01-28 23:56:37 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
Lto::No => {}
|
2019-01-28 23:56:37 +01:00
|
|
|
};
|
2019-01-19 21:59:34 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
fn output_filename(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-o").arg(path);
|
|
|
|
}
|
|
|
|
|
2020-04-05 02:58:32 +03:00
|
|
|
fn finalize(&mut self) {
|
2019-01-29 20:54:23 +01:00
|
|
|
// Provide the linker with fallback to internal `target-cpu`.
|
|
|
|
self.cmd.arg("--fallback-arch").arg(match self.sess.opts.cg.target_cpu {
|
|
|
|
Some(ref s) => s,
|
2020-11-08 14:27:51 +03:00
|
|
|
None => &self.sess.target.cpu,
|
2019-01-29 20:54:23 +01:00
|
|
|
});
|
2019-01-19 21:59:34 +01:00
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_dylib(&mut self, _lib: Symbol) {
|
2019-01-19 21:59:34 +01:00
|
|
|
panic!("external dylibs not supported")
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_rust_dylib(&mut self, _lib: Symbol, _path: &Path) {
|
2019-01-19 21:59:34 +01:00
|
|
|
panic!("external dylibs not supported")
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_staticlib(&mut self, _lib: Symbol) {
|
2019-01-19 21:59:34 +01:00
|
|
|
panic!("staticlibs not supported")
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_whole_staticlib(&mut self, _lib: Symbol, _search_path: &[PathBuf]) {
|
2019-01-19 21:59:34 +01:00
|
|
|
panic!("staticlibs not supported")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn framework_path(&mut self, _path: &Path) {
|
|
|
|
panic!("frameworks not supported")
|
|
|
|
}
|
|
|
|
|
2019-09-05 11:23:45 +10:00
|
|
|
fn link_framework(&mut self, _framework: Symbol) {
|
2019-01-19 21:59:34 +01:00
|
|
|
panic!("frameworks not supported")
|
|
|
|
}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn full_relro(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn partial_relro(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn no_relro(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn gc_sections(&mut self, _keep_metadata: bool) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn pgo_gen(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2020-04-29 20:47:07 +03:00
|
|
|
fn no_crt_objects(&mut self) {}
|
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn no_default_libraries(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2020-07-06 16:10:42 +01:00
|
|
|
fn control_flow_guard(&mut self) {}
|
2020-01-13 13:25:39 +00:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn export_symbols(&mut self, _tmpdir: &Path, _crate_type: CrateType) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn subsystem(&mut self, _subsystem: &str) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn group_start(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn group_end(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
|
2019-12-22 17:42:04 -05:00
|
|
|
fn linker_plugin_lto(&mut self) {}
|
2019-01-19 21:59:34 +01:00
|
|
|
}
|