2015-05-08 15:31:23 -07:00
|
|
|
// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
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::collections::HashMap;
|
-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};
|
2015-05-08 15:31:23 -07:00
|
|
|
use std::path::{Path, PathBuf};
|
|
|
|
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
use back::archive;
|
2017-08-25 20:16:51 -07:00
|
|
|
use back::command::Command;
|
2017-09-13 13:22:20 -07:00
|
|
|
use back::symbol_export;
|
2016-11-30 10:03:42 -05:00
|
|
|
use rustc::hir::def_id::{LOCAL_CRATE, CrateNum};
|
2017-09-13 13:22:20 -07:00
|
|
|
use rustc::middle::dependency_format::Linkage;
|
2017-05-27 20:48:09 +02:00
|
|
|
use rustc::session::Session;
|
2018-04-25 15:45:04 +02:00
|
|
|
use rustc::session::config::{self, CrateType, OptLevel, DebugInfoLevel,
|
|
|
|
CrossLangLto};
|
2017-09-13 13:22:20 -07:00
|
|
|
use rustc::ty::TyCtxt;
|
2017-12-08 21:18:21 +02:00
|
|
|
use rustc_target::spec::{LinkerFlavor, LldFlavor};
|
2017-02-03 14:58:13 +00:00
|
|
|
use serialize::{json, Encoder};
|
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.
|
|
|
|
pub struct LinkerInfo {
|
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
|
|
|
exports: HashMap<CrateType, Vec<String>>,
|
2016-05-25 01:45:25 +03:00
|
|
|
}
|
|
|
|
|
2017-09-13 13:22:20 -07:00
|
|
|
impl LinkerInfo {
|
|
|
|
pub fn new(tcx: TyCtxt) -> LinkerInfo {
|
2016-05-25 01:45:25 +03:00
|
|
|
LinkerInfo {
|
2017-09-13 13:22:20 -07:00
|
|
|
exports: tcx.sess.crate_types.borrow().iter().map(|&c| {
|
|
|
|
(c, exported_symbols(tcx, c))
|
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
|
|
|
}).collect(),
|
2016-05-25 01:45:25 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-13 13:22:20 -07:00
|
|
|
pub fn to_linker<'a>(&'a self,
|
|
|
|
cmd: Command,
|
2018-07-11 12:49:11 +02:00
|
|
|
sess: &'a Session) -> Box<dyn Linker+'a> {
|
-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
|
|
|
match sess.linker_flavor() {
|
2018-02-10 12:09:25 -08:00
|
|
|
LinkerFlavor::Lld(LldFlavor::Link) |
|
-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
|
|
|
LinkerFlavor::Msvc => {
|
|
|
|
Box::new(MsvcLinker {
|
2017-08-06 22:54:09 -07:00
|
|
|
cmd,
|
|
|
|
sess,
|
-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
|
|
|
info: self
|
2018-07-11 12:49:11 +02:00
|
|
|
}) 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
|
|
|
}
|
|
|
|
LinkerFlavor::Em => {
|
|
|
|
Box::new(EmLinker {
|
2017-08-06 22:54:09 -07:00
|
|
|
cmd,
|
|
|
|
sess,
|
-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
|
|
|
info: self
|
2018-07-11 12:49:11 +02:00
|
|
|
}) 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
|
|
|
}
|
|
|
|
LinkerFlavor::Gcc => {
|
|
|
|
Box::new(GccLinker {
|
2017-08-06 22:54:09 -07:00
|
|
|
cmd,
|
|
|
|
sess,
|
-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
|
|
|
info: self,
|
|
|
|
hinted_static: false,
|
|
|
|
is_ld: false,
|
2018-07-11 12:49:11 +02:00
|
|
|
}) 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
|
|
|
}
|
2018-02-10 12:09:25 -08:00
|
|
|
|
|
|
|
LinkerFlavor::Lld(LldFlavor::Ld) |
|
|
|
|
LinkerFlavor::Lld(LldFlavor::Ld64) |
|
-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
|
|
|
LinkerFlavor::Ld => {
|
|
|
|
Box::new(GccLinker {
|
2017-08-06 22:54:09 -07:00
|
|
|
cmd,
|
|
|
|
sess,
|
-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
|
|
|
info: self,
|
|
|
|
hinted_static: false,
|
|
|
|
is_ld: true,
|
2018-07-11 12:49:11 +02:00
|
|
|
}) 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
|
|
|
}
|
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) => {
|
|
|
|
Box::new(WasmLd {
|
|
|
|
cmd,
|
2018-06-01 10:20:00 -07:00
|
|
|
sess,
|
2018-07-11 12:49:11 +02:00
|
|
|
}) as Box<dyn Linker>
|
2017-10-22 20:01:00 -07:00
|
|
|
}
|
2016-05-25 01:45:25 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-05-08 15:31:23 -07:00
|
|
|
|
|
|
|
/// Linker abstraction used by back::link to build up the command to invoke a
|
|
|
|
/// 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
|
|
|
|
/// MSVC linker (e.g. `link.exe`) is being used.
|
|
|
|
pub trait Linker {
|
|
|
|
fn link_dylib(&mut self, lib: &str);
|
2015-06-25 00:33:52 -07:00
|
|
|
fn link_rust_dylib(&mut self, lib: &str, path: &Path);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn link_framework(&mut self, framework: &str);
|
|
|
|
fn link_staticlib(&mut self, lib: &str);
|
|
|
|
fn link_rlib(&mut self, lib: &Path);
|
2015-07-07 21:33:44 -07:00
|
|
|
fn link_whole_rlib(&mut self, lib: &Path);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn link_whole_staticlib(&mut self, lib: &str, search_path: &[PathBuf]);
|
|
|
|
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);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn position_independent_executable(&mut self);
|
2018-02-08 07:48:16 -05:00
|
|
|
fn no_position_independent_executable(&mut self);
|
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);
|
2015-07-04 23:25:38 +02:00
|
|
|
fn debuginfo(&mut self);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn no_default_libraries(&mut self);
|
|
|
|
fn build_dylib(&mut self, out_filename: &Path);
|
2017-08-22 16:24:29 -05:00
|
|
|
fn build_static_executable(&mut self);
|
2015-05-08 15:31:23 -07:00
|
|
|
fn args(&mut self, args: &[String]);
|
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);
|
2018-04-25 15:45:04 +02:00
|
|
|
fn cross_lang_lto(&mut self);
|
2017-03-23 18:03:39 -07:00
|
|
|
// Should have been finalize(self), but we don't support self-by-value on trait objects (yet?).
|
|
|
|
fn finalize(&mut self) -> Command;
|
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
|
|
|
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,
|
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
|
|
|
|
///
|
|
|
|
/// These arguments need to be prepended with '-Wl,' when a gcc-style linker is used
|
|
|
|
fn linker_arg<S>(&mut self, arg: S) -> &mut Self
|
|
|
|
where S: AsRef<OsStr>
|
|
|
|
{
|
|
|
|
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 {
|
|
|
|
!self.sess.target.target.options.is_like_osx
|
|
|
|
}
|
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) {
|
|
|
|
if !self.takes_hints() { return }
|
|
|
|
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) {
|
|
|
|
if !self.takes_hints() { return }
|
|
|
|
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
|
|
|
|
|
|
|
fn push_cross_lang_lto_args(&mut self, plugin_path: Option<&OsStr>) {
|
|
|
|
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",
|
|
|
|
config::OptLevel::Default => "O2",
|
|
|
|
config::OptLevel::Aggressive => "O3",
|
|
|
|
config::OptLevel::Size => "Os",
|
|
|
|
config::OptLevel::SizeMin => "Oz",
|
|
|
|
};
|
|
|
|
|
|
|
|
self.linker_arg(&format!("-plugin-opt={}", opt_level));
|
|
|
|
self.linker_arg(&format!("-plugin-opt=mcpu={}", self.sess.target_cpu()));
|
|
|
|
|
|
|
|
match self.sess.opts.cg.lto {
|
|
|
|
config::Lto::Thin |
|
|
|
|
config::Lto::ThinLocal => {
|
|
|
|
self.linker_arg(&format!("-plugin-opt=thin"));
|
|
|
|
}
|
|
|
|
config::Lto::Fat |
|
|
|
|
config::Lto::Yes |
|
|
|
|
config::Lto::No => {
|
|
|
|
// default to regular LTO
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
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> {
|
2017-03-23 18:03:39 -07:00
|
|
|
fn link_dylib(&mut self, lib: &str) { self.hint_dynamic(); self.cmd.arg("-l").arg(lib); }
|
|
|
|
fn link_staticlib(&mut self, lib: &str) { self.hint_static(); self.cmd.arg("-l").arg(lib); }
|
|
|
|
fn link_rlib(&mut self, lib: &Path) { self.hint_static(); self.cmd.arg(lib); }
|
2015-05-08 15:31:23 -07:00
|
|
|
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 position_independent_executable(&mut self) { self.cmd.arg("-pie"); }
|
2018-02-08 07:48:16 -05:00
|
|
|
fn no_position_independent_executable(&mut self) { self.cmd.arg("-no-pie"); }
|
2017-07-10 20:57:45 +02:00
|
|
|
fn full_relro(&mut self) { self.linker_arg("-z,relro,-z,now"); }
|
2018-02-22 21:28:20 +01:00
|
|
|
fn partial_relro(&mut self) { self.linker_arg("-z,relro"); }
|
|
|
|
fn no_relro(&mut self) { self.linker_arg("-z,norelro"); }
|
2017-08-22 16:24:29 -05:00
|
|
|
fn build_static_executable(&mut self) { self.cmd.arg("-static"); }
|
2015-05-08 15:31:23 -07:00
|
|
|
fn args(&mut self, args: &[String]) { self.cmd.args(args); }
|
|
|
|
|
2015-06-25 00:33:52 -07:00
|
|
|
fn link_rust_dylib(&mut self, lib: &str, _path: &Path) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_dynamic();
|
2015-06-25 00:33:52 -07:00
|
|
|
self.cmd.arg("-l").arg(lib);
|
|
|
|
}
|
|
|
|
|
2015-05-08 15:31:23 -07:00
|
|
|
fn link_framework(&mut self, framework: &str) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_dynamic();
|
2015-05-08 15:31:23 -07:00
|
|
|
self.cmd.arg("-framework").arg(framework);
|
|
|
|
}
|
|
|
|
|
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.
|
2015-05-08 15:31:23 -07:00
|
|
|
fn link_whole_staticlib(&mut self, lib: &str, search_path: &[PathBuf]) {
|
2017-03-23 18:03:39 -07:00
|
|
|
self.hint_static();
|
2015-05-08 15:31:23 -07:00
|
|
|
let target = &self.sess.target.target;
|
|
|
|
if !target.options.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("--whole-archive").cmd.arg("-l").arg(lib);
|
|
|
|
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.
|
-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
|
|
|
let mut v = OsString::from("-force_load,");
|
trans: Use LLVM's writeArchive to modify archives
We have previously always relied upon an external tool, `ar`, to modify archives
that the compiler produces (staticlibs, rlibs, etc). This approach, however, has
a number of downsides:
* Spawning a process is relatively expensive for small compilations
* Encoding arguments across process boundaries often incurs unnecessary overhead
or lossiness. For example `ar` has a tough time dealing with files that have
the same name in archives, and the compiler copies many files around to ensure
they can be passed to `ar` in a reasonable fashion.
* Most `ar` programs found do **not** have the ability to target arbitrary
platforms, so this is an extra tool which needs to be found/specified when
cross compiling.
The LLVM project has had a tool called `llvm-ar` for quite some time now, but it
wasn't available in the standard LLVM libraries (it was just a standalone
program). Recently, however, in LLVM 3.7, this functionality has been moved to a
library and is now accessible by consumers of LLVM via the `writeArchive`
function.
This commit migrates our archive bindings to no longer invoke `ar` by default
but instead make a library call to LLVM to do various operations. This solves
all of the downsides listed above:
* Archive management is now much faster, for example creating a "hello world"
staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also
recently started requiring modification of rlibs, and linking a hello world
dynamic library is now 2x faster.
* The compiler is now one step closer to "hassle free" cross compilation because
no external tool is needed for managing archives, LLVM does the right thing!
This commit does not remove support for calling a system `ar` utility currently.
We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward
(so the system LLVM can be used wherever possible), and in these cases we must
shell out to a system utility. All nightly builds of Rust, however, will stop
needing a system `ar`.
2015-07-09 00:14:20 -07:00
|
|
|
v.push(&archive::find_library(lib, search_path, &self.sess));
|
-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(&v);
|
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();
|
2015-07-07 21:33:44 -07:00
|
|
|
if self.sess.target.target.options.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
|
|
|
let mut v = OsString::from("-force_load,");
|
2015-07-07 21:33:44 -07:00
|
|
|
v.push(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(&v);
|
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.
|
|
|
|
if self.sess.target.target.options.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");
|
2016-01-28 14:02:31 +03:00
|
|
|
} else if self.sess.target.target.options.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
|
|
|
self.linker_arg("-z");
|
|
|
|
self.linker_arg("ignore");
|
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) {
|
|
|
|
if !self.sess.target.target.options.linker_is_gnu { return }
|
|
|
|
|
|
|
|
// GNU-style linkers support optimization with -O. GNU ld doesn't
|
|
|
|
// need a numeric argument, but other linkers do.
|
2015-12-31 16:50:06 +13: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) {
|
|
|
|
if !self.sess.target.target.options.linker_is_gnu { return }
|
|
|
|
|
|
|
|
// 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");
|
|
|
|
}
|
|
|
|
|
2015-07-04 23:25:38 +02:00
|
|
|
fn debuginfo(&mut self) {
|
2018-03-20 16:23:31 +01:00
|
|
|
match self.sess.opts.debuginfo {
|
|
|
|
DebugInfoLevel::NoDebugInfo => {
|
|
|
|
// If we are building without debuginfo enabled and we were called with
|
|
|
|
// `-Zstrip-debuginfo-if-disabled=yes`, tell the linker to strip any debuginfo
|
|
|
|
// found when linking to get rid of symbols from libstd.
|
|
|
|
match self.sess.opts.debugging_opts.strip_debuginfo_if_disabled {
|
|
|
|
Some(true) => { self.linker_arg("-S"); },
|
|
|
|
_ => {},
|
|
|
|
}
|
|
|
|
},
|
|
|
|
_ => {},
|
|
|
|
};
|
2015-07-04 23:25:38 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
fn build_dylib(&mut self, out_filename: &Path) {
|
|
|
|
// On mac we need to tell the linker to let this library be rpathed
|
|
|
|
if self.sess.target.target.options.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.cmd.arg("-dynamiclib");
|
|
|
|
self.linker_arg("-dylib");
|
2015-05-08 15:31:23 -07:00
|
|
|
|
2016-12-17 14:11:02 -08:00
|
|
|
// 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 {
|
-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
|
|
|
let mut v = OsString::from("-install_name,@rpath/");
|
2015-05-08 15:31:23 -07:00
|
|
|
v.push(out_filename.file_name().unwrap());
|
-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(&v);
|
2015-05-08 15:31:23 -07:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
self.cmd.arg("-shared");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-25 01:45:25 +03:00
|
|
|
fn export_symbols(&mut self, tmpdir: &Path, crate_type: CrateType) {
|
2016-05-10 14:17:57 -07:00
|
|
|
// If we're compiling a dylib, then we let symbol visibility in object
|
|
|
|
// files to take care of whether they're exported or not.
|
|
|
|
//
|
|
|
|
// If we're compiling a cdylib, however, 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.
|
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
|
|
|
if crate_type == CrateType::CrateTypeDylib ||
|
2016-10-03 09:49:39 -07:00
|
|
|
crate_type == CrateType::CrateTypeProcMacro {
|
2016-05-10 14:17:57 -07:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2016-08-13 14:09:43 +05:00
|
|
|
let mut arg = OsString::new();
|
2016-05-10 14:17:57 -07:00
|
|
|
let path = tmpdir.join("list");
|
2016-08-13 14:09:43 +05:00
|
|
|
|
2016-12-01 14:57:46 -05:00
|
|
|
debug!("EXPORTED SYMBOLS:");
|
|
|
|
|
2016-11-30 13:16:53 -05:00
|
|
|
if self.sess.target.target.options.is_like_osx {
|
|
|
|
// Write a plain, newline-separated list of symbols
|
2016-08-13 14:09:43 +05:00
|
|
|
let res = (|| -> io::Result<()> {
|
|
|
|
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
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
})();
|
|
|
|
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
|
|
|
}
|
|
|
|
} else {
|
2016-11-30 13:16:53 -05:00
|
|
|
// Write an LD version script
|
2016-08-13 14:09:43 +05:00
|
|
|
let res = (|| -> io::Result<()> {
|
|
|
|
let mut f = BufWriter::new(File::create(&path)?);
|
2016-11-30 13:16:53 -05:00
|
|
|
writeln!(f, "{{\n global:")?;
|
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
|
|
|
}
|
2016-11-30 13:16:53 -05:00
|
|
|
writeln!(f, "\n local:\n *;\n}};")?;
|
2016-08-13 14:09:43 +05:00
|
|
|
Ok(())
|
|
|
|
})();
|
|
|
|
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
|
|
|
|
2016-11-30 13:16:53 -05:00
|
|
|
if self.sess.target.target.options.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,");
|
2016-11-30 13:16:53 -05:00
|
|
|
} else if self.sess.target.target.options.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,")
|
|
|
|
}
|
|
|
|
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) {
|
2017-04-10 09:53:24 -05:00
|
|
|
self.linker_arg(&format!("--subsystem,{}", subsystem));
|
2016-10-31 09:36:30 -07:00
|
|
|
}
|
2017-03-23 18:03:39 -07:00
|
|
|
|
|
|
|
fn finalize(&mut self) -> Command {
|
|
|
|
self.hint_dynamic(); // Reset to default before returning the composed command line.
|
|
|
|
let mut cmd = Command::new("");
|
|
|
|
::std::mem::swap(&mut cmd, &mut self.cmd);
|
|
|
|
cmd
|
|
|
|
}
|
2018-03-23 14:33:22 -07:00
|
|
|
|
|
|
|
fn group_start(&mut self) {
|
|
|
|
if !self.sess.target.target.options.is_like_osx {
|
|
|
|
self.linker_arg("--start-group");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn group_end(&mut self) {
|
|
|
|
if !self.sess.target.target.options.is_like_osx {
|
|
|
|
self.linker_arg("--end-group");
|
|
|
|
}
|
|
|
|
}
|
2018-04-25 15:45:04 +02:00
|
|
|
|
|
|
|
fn cross_lang_lto(&mut self) {
|
|
|
|
match self.sess.opts.debugging_opts.cross_lang_lto {
|
2018-07-06 14:08:40 +02:00
|
|
|
CrossLangLto::Disabled => {
|
2018-04-25 15:45:04 +02:00
|
|
|
// Nothing to do
|
|
|
|
}
|
2018-07-03 16:33:11 +02:00
|
|
|
CrossLangLto::LinkerPluginAuto => {
|
|
|
|
self.push_cross_lang_lto_args(None);
|
|
|
|
}
|
2018-04-25 15:45:04 +02:00
|
|
|
CrossLangLto::LinkerPlugin(ref path) => {
|
2018-07-03 16:33:11 +02:00
|
|
|
self.push_cross_lang_lto_args(Some(path.as_os_str()));
|
2018-04-25 15:45:04 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
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,
|
|
|
|
info: &'a LinkerInfo
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Linker for MsvcLinker<'a> {
|
|
|
|
fn link_rlib(&mut self, lib: &Path) { self.cmd.arg(lib); }
|
|
|
|
fn add_object(&mut self, path: &Path) { self.cmd.arg(path); }
|
|
|
|
fn args(&mut self, args: &[String]) { self.cmd.args(args); }
|
2015-12-04 22:36:01 -05:00
|
|
|
|
|
|
|
fn build_dylib(&mut self, out_filename: &Path) {
|
|
|
|
self.cmd.arg("/DLL");
|
|
|
|
let mut arg: OsString = "/IMPLIB:".into();
|
|
|
|
arg.push(out_filename.with_extension("dll.lib"));
|
|
|
|
self.cmd.arg(arg);
|
|
|
|
}
|
|
|
|
|
2017-08-22 16:24:29 -05:00
|
|
|
fn build_static_executable(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
fn link_dylib(&mut self, lib: &str) {
|
|
|
|
self.cmd.arg(&format!("{}.lib", lib));
|
|
|
|
}
|
2015-06-25 00:33:52 -07:00
|
|
|
|
|
|
|
fn link_rust_dylib(&mut self, lib: &str, path: &Path) {
|
|
|
|
// 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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-11 14:57:21 -07:00
|
|
|
fn link_staticlib(&mut self, lib: &str) {
|
|
|
|
self.cmd.arg(&format!("{}.lib", lib));
|
|
|
|
}
|
|
|
|
|
|
|
|
fn position_independent_executable(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2018-02-08 07:48:16 -05:00
|
|
|
fn no_position_independent_executable(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
}
|
|
|
|
|
2015-05-11 14:57:21 -07:00
|
|
|
fn no_default_libraries(&mut self) {
|
|
|
|
// Currently we don't pass the /NODEFAULTLIB flag to the linker on MSVC
|
|
|
|
// as there's been trouble in the past of linking the C++ standard
|
|
|
|
// library required by LLVM. This likely needs to happen one day, but
|
|
|
|
// in general Windows is also a more controlled environment than
|
|
|
|
// Unix, so it's not necessarily as critical that this be implemented.
|
|
|
|
//
|
|
|
|
// Note that there are also some licensing worries about statically
|
|
|
|
// linking some libraries which require a specific agreement, so it may
|
|
|
|
// not ever be possible for us to pass this flag.
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
fn link_framework(&mut self, _framework: &str) {
|
2016-03-29 01:46:02 +02:00
|
|
|
bug!("frameworks are not supported on windows")
|
2015-05-11 14:57:21 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_staticlib(&mut self, lib: &str, _search_path: &[PathBuf]) {
|
|
|
|
// not supported?
|
|
|
|
self.link_staticlib(lib);
|
|
|
|
}
|
2015-07-07 21:33:44 -07:00
|
|
|
fn link_whole_rlib(&mut self, path: &Path) {
|
|
|
|
// not supported?
|
|
|
|
self.link_rlib(path);
|
|
|
|
}
|
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.
|
|
|
|
}
|
|
|
|
|
2015-07-04 23:25:38 +02:00
|
|
|
fn debuginfo(&mut self) {
|
2015-09-18 20:24:43 -04:00
|
|
|
// This will cause the Microsoft linker to generate a PDB file
|
|
|
|
// from the CodeView line tables in the object files.
|
|
|
|
self.cmd.arg("/DEBUG");
|
2017-07-13 10:03:07 -07:00
|
|
|
|
|
|
|
// This will cause the Microsoft linker to embed .natvis info into the the PDB file
|
|
|
|
let sysroot = self.sess.sysroot();
|
|
|
|
let natvis_dir_path = sysroot.join("lib\\rustlib\\etc");
|
|
|
|
if let Ok(natvis_dir) = fs::read_dir(&natvis_dir_path) {
|
2017-09-10 19:37:59 -07:00
|
|
|
// LLVM 5.0.0's lld-link frontend doesn't yet recognize, and chokes
|
|
|
|
// on, the /NATVIS:... flags. LLVM 6 (or earlier) should at worst ignore
|
|
|
|
// them, eventually mooting this workaround, per this landed patch:
|
|
|
|
// https://github.com/llvm-mirror/lld/commit/27b9c4285364d8d76bb43839daa100
|
|
|
|
if let Some(ref linker_path) = self.sess.opts.cg.linker {
|
|
|
|
if let Some(linker_name) = Path::new(&linker_path).file_stem() {
|
|
|
|
if linker_name.to_str().unwrap().to_lowercase() == "lld-link" {
|
|
|
|
self.sess.warn("not embedding natvis: lld-link may not support the flag");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-07-13 10:03:07 -07:00
|
|
|
for entry in natvis_dir {
|
|
|
|
match entry {
|
|
|
|
Ok(entry) => {
|
|
|
|
let path = entry.path();
|
2017-07-20 16:09:24 -07:00
|
|
|
if path.extension() == Some("natvis".as_ref()) {
|
|
|
|
let mut arg = OsString::from("/NATVIS:");
|
|
|
|
arg.push(path);
|
|
|
|
self.cmd.arg(arg);
|
2017-07-13 10:03:07 -07:00
|
|
|
}
|
|
|
|
},
|
|
|
|
Err(err) => {
|
|
|
|
self.sess.warn(&format!("error enumerating natvis directory: {}", err));
|
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
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.
|
2016-05-10 14:17:57 -07:00
|
|
|
fn export_symbols(&mut self,
|
|
|
|
tmpdir: &Path,
|
|
|
|
crate_type: CrateType) {
|
2015-07-28 17:19:08 -07:00
|
|
|
let path = tmpdir.join("lib.def");
|
|
|
|
let res = (|| -> io::Result<()> {
|
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
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
})();
|
|
|
|
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
|
|
|
|
|
|
|
fn finalize(&mut self) -> Command {
|
|
|
|
let mut cmd = Command::new("");
|
|
|
|
::std::mem::swap(&mut cmd, &mut self.cmd);
|
|
|
|
cmd
|
|
|
|
}
|
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
|
|
|
|
|
|
|
fn cross_lang_lto(&mut self) {
|
|
|
|
// 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,
|
|
|
|
info: &'a LinkerInfo
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a> Linker for EmLinker<'a> {
|
|
|
|
fn include_path(&mut self, path: &Path) {
|
|
|
|
self.cmd.arg("-L").arg(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_staticlib(&mut self, lib: &str) {
|
|
|
|
self.cmd.arg("-l").arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
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 link_dylib(&mut self, lib: &str) {
|
|
|
|
// Emscripten always links statically
|
|
|
|
self.link_staticlib(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_staticlib(&mut self, lib: &str, _search_path: &[PathBuf]) {
|
|
|
|
// not supported?
|
|
|
|
self.link_staticlib(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_rlib(&mut self, lib: &Path) {
|
|
|
|
// not supported?
|
|
|
|
self.link_rlib(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_rust_dylib(&mut self, lib: &str, _path: &Path) {
|
|
|
|
self.link_dylib(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_rlib(&mut self, lib: &Path) {
|
|
|
|
self.add_object(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn position_independent_executable(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
2018-02-08 07:48:16 -05:00
|
|
|
fn no_position_independent_executable(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
|
|
|
|
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 args(&mut self, args: &[String]) {
|
|
|
|
self.cmd.args(args);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn framework_path(&mut self, _path: &Path) {
|
|
|
|
bug!("frameworks are not supported on Emscripten")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_framework(&mut self, _framework: &str) {
|
|
|
|
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",
|
|
|
|
OptLevel::SizeMin => "-Oz"
|
|
|
|
});
|
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?
|
|
|
|
}
|
|
|
|
|
2017-02-03 14:58:13 +00:00
|
|
|
fn debuginfo(&mut self) {
|
|
|
|
// Preserve names or generate source maps depending on debug info
|
|
|
|
self.cmd.arg(match self.sess.opts.debuginfo {
|
|
|
|
DebugInfoLevel::NoDebugInfo => "-g0",
|
|
|
|
DebugInfoLevel::LimitedDebugInfo => "-g3",
|
|
|
|
DebugInfoLevel::FullDebugInfo => "-g4"
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
fn no_default_libraries(&mut self) {
|
|
|
|
self.cmd.args(&["-s", "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]"]);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn build_dylib(&mut self, _out_filename: &Path) {
|
|
|
|
bug!("building dynamic library is unsupported on Emscripten")
|
|
|
|
}
|
2017-08-22 16:24:29 -05:00
|
|
|
|
|
|
|
fn build_static_executable(&mut self) {
|
|
|
|
// noop
|
|
|
|
}
|
2017-02-03 14:58:13 +00:00
|
|
|
|
|
|
|
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() {
|
|
|
|
encoder.emit_seq_elt(i, |encoder| {
|
|
|
|
encoder.emit_str(&("_".to_string() + sym))
|
|
|
|
})?;
|
|
|
|
}
|
|
|
|
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
|
|
|
|
|
|
|
fn finalize(&mut self) -> Command {
|
|
|
|
let mut cmd = Command::new("");
|
|
|
|
::std::mem::swap(&mut cmd, &mut self.cmd);
|
|
|
|
cmd
|
|
|
|
}
|
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
|
|
|
|
|
|
|
fn cross_lang_lto(&mut self) {
|
|
|
|
// Do nothing
|
|
|
|
}
|
2017-02-03 14:58:13 +00:00
|
|
|
}
|
|
|
|
|
2017-09-13 13:22:20 -07:00
|
|
|
fn exported_symbols(tcx: TyCtxt, crate_type: CrateType) -> Vec<String> {
|
2016-11-30 10:03:42 -05:00
|
|
|
let mut symbols = Vec::new();
|
2016-05-10 14:17:57 -07:00
|
|
|
|
2017-10-31 12:42:03 +01:00
|
|
|
let export_threshold = symbol_export::crates_export_threshold(&[crate_type]);
|
2018-02-27 17:52:07 +01:00
|
|
|
for &(symbol, level) in tcx.exported_symbols(LOCAL_CRATE).iter() {
|
2017-09-13 13:22:20 -07:00
|
|
|
if level.is_below_threshold(export_threshold) {
|
2018-02-27 17:52:07 +01:00
|
|
|
symbols.push(symbol.symbol_name(tcx).to_string());
|
2017-09-13 13:22:20 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let formats = tcx.sess.dependency_formats.borrow();
|
2016-05-25 01:45:25 +03:00
|
|
|
let deps = formats[&crate_type].iter();
|
2016-11-30 10:03:42 -05:00
|
|
|
|
|
|
|
for (index, dep_format) in deps.enumerate() {
|
|
|
|
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.
|
2018-02-27 17:52:07 +01:00
|
|
|
for &(symbol, level) in tcx.exported_symbols(cnum).iter() {
|
2017-09-13 13:22:20 -07:00
|
|
|
if level.is_below_threshold(export_threshold) {
|
2018-02-27 17:52:07 +01:00
|
|
|
symbols.push(symbol.symbol_name(tcx).to_string());
|
2017-09-13 13:22:20 -07:00
|
|
|
}
|
|
|
|
}
|
2016-05-10 14:17:57 -07:00
|
|
|
}
|
2016-11-30 10:03:42 -05:00
|
|
|
}
|
|
|
|
|
2016-05-25 01:45:25 +03:00
|
|
|
symbols
|
2016-05-10 14:17:57 -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
|
|
|
|
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,
|
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-06-01 10:20:00 -07:00
|
|
|
impl<'a> Linker for 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
|
|
|
fn link_dylib(&mut self, lib: &str) {
|
|
|
|
self.cmd.arg("-l").arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_staticlib(&mut self, lib: &str) {
|
|
|
|
self.cmd.arg("-l").arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn position_independent_executable(&mut self) {
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:28:20 +01:00
|
|
|
fn full_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
|
|
|
fn partial_relro(&mut self) {
|
|
|
|
}
|
|
|
|
|
2018-02-22 21:28:20 +01: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
|
|
|
}
|
|
|
|
|
|
|
|
fn build_static_executable(&mut self) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn args(&mut self, args: &[String]) {
|
|
|
|
self.cmd.args(args);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_rust_dylib(&mut self, lib: &str, _path: &Path) {
|
|
|
|
self.cmd.arg("-l").arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_framework(&mut self, _framework: &str) {
|
|
|
|
panic!("frameworks not supported")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn link_whole_staticlib(&mut self, lib: &str, _search_path: &[PathBuf]) {
|
|
|
|
self.cmd.arg("-l").arg(lib);
|
|
|
|
}
|
|
|
|
|
|
|
|
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",
|
|
|
|
OptLevel::SizeMin => "-O2"
|
|
|
|
});
|
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-03-19 22:29:58 +01:00
|
|
|
fn pgo_gen(&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
|
|
|
fn debuginfo(&mut self) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn no_default_libraries(&mut self) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn build_dylib(&mut self, _out_filename: &Path) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn export_symbols(&mut self, _tmpdir: &Path, _crate_type: CrateType) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn subsystem(&mut self, _subsystem: &str) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn no_position_independent_executable(&mut self) {
|
|
|
|
}
|
|
|
|
|
|
|
|
fn finalize(&mut self) -> Command {
|
2018-04-26 06:56:37 -07:00
|
|
|
// There have been reports in the wild (rustwasm/wasm-bindgen#119) of
|
|
|
|
// using threads causing weird hangs and bugs. Disable it entirely as
|
|
|
|
// this isn't yet the bottleneck of compilation at all anyway.
|
|
|
|
self.cmd.arg("--no-threads");
|
|
|
|
|
2018-06-01 10:20:00 -07:00
|
|
|
// By default LLD only gives us one page of stack (64k) which is a
|
|
|
|
// little small. Default to a larger stack closer to other PC platforms
|
|
|
|
// (1MB) and users can always inject their own link-args to override this.
|
2018-04-19 14:51:59 -07:00
|
|
|
self.cmd.arg("-z").arg("stack-size=1048576");
|
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-06-01 10:20:00 -07:00
|
|
|
// By default LLD's memory layout is:
|
|
|
|
//
|
|
|
|
// 1. First, a blank page
|
|
|
|
// 2. Next, all static data
|
|
|
|
// 3. Finally, the main stack (which grows down)
|
|
|
|
//
|
|
|
|
// This has the unfortunate consequence that on stack overflows you
|
|
|
|
// corrupt static data and can cause some exceedingly weird bugs. To
|
|
|
|
// help detect this a little sooner we instead request that the stack is
|
|
|
|
// placed before static data.
|
|
|
|
//
|
|
|
|
// This means that we'll generate slightly larger binaries as references
|
|
|
|
// to static data will take more bytes in the ULEB128 encoding, but
|
|
|
|
// stack overflow will be guaranteed to trap as it underflows instead of
|
|
|
|
// corrupting static data.
|
|
|
|
self.cmd.arg("--stack-first");
|
|
|
|
|
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
|
|
|
// FIXME we probably shouldn't pass this but instead pass an explicit
|
|
|
|
// whitelist of symbols we'll allow to be undefined. Unfortunately
|
|
|
|
// though we can't handle symbols like `log10` that LLVM injects at a
|
|
|
|
// super late date without actually parsing object files. For now let's
|
|
|
|
// stick to this and hopefully fix it before stabilization happens.
|
|
|
|
self.cmd.arg("--allow-undefined");
|
|
|
|
|
|
|
|
// For now we just never have an entry symbol
|
|
|
|
self.cmd.arg("--no-entry");
|
|
|
|
|
|
|
|
let mut cmd = Command::new("");
|
|
|
|
::std::mem::swap(&mut cmd, &mut self.cmd);
|
|
|
|
cmd
|
|
|
|
}
|
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
|
|
|
|
|
|
|
fn cross_lang_lto(&mut self) {
|
|
|
|
// 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
|
|
|
}
|