Commit Graph

39 Commits

Author SHA1 Message Date
Niko Matsakis
a47fd3df89 make #[unwind] attribute specify expectations more clearly
You can now choose between the following:

- `#[unwind(allowed)]`
- `#[unwind(aborts)]`

Per rust-lang/rust#48251, the default is `#[unwind(allowed)]`, though
I think we should change this eventually.
2018-02-20 19:12:52 -05:00
bors
385ef1514c Auto merge of #47663 - malbarbo:mips-crt-static, r=alexcrichton
Do not assume dynamic linking for musl/mips[el] targets

All musl targets except mips[el] assume static linking by default. This can be [confusing](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084).

When the musl/mips[el] targets was [added](https://github.com/rust-lang/rust/pull/31298), dynamic linking was chosen because of binary size concerns, and probably also because libunwind [didn't](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084/8) supported mips.

Now that we have `crt-static` target-feature (the user can choose dynamic link for musl targets), and libunwind [6.0](https://github.com/llvm-mirror/libunwind/commits/release_60) add support to mips, we do not need to assume dynamic linking.
2018-01-28 23:30:15 +00:00
bors
5c41fcec4c Auto merge of #47571 - FenrirWolf:libunwind, r=alexcrichton
Match libunwind's EABI selection with libpanic_unwind

Currently, the `libunwind` crate will only select the ARM EABI if it is compiling for ARM/Linux or Android targets. `libpanic_unwind`, however, will choose the ARM EABI if the target arch is ARM and the OS is not iOS. This means that if one tries to enable unwinding for a non-standard ARM target (such as implementing a custom stdlib via Xargo, for example), then the two crates can potentially disagree about which EABI is being targeted.

This PR makes `libunwind` use the [same logic](https://github.com/rust-lang/rust/blob/master/src/libpanic_unwind/gcc.rs#L139-L146) as `libpanic_unwind` when choosing the EABI.

I noticed there are a few comments about certain functions only differing on Android or ARM/Linux, but I *think* that those differences apply to the ARM EABI in general. Let me know if I'm wrong about that.
2018-01-27 00:28:34 +00:00
Marco A L Barbosa
68db72d8cd Do not assume dynamic linking for musl/mips[el] targets
All musl targets except mips[el] assume static linking by default. This
can be confusing
https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084

When the musl/mips[el] targets was
[added](https://github.com/rust-lang/rust/pull/31298), dynamic linking
was chosen because of binary size concerns, and probably also because
libunwind
[didn't](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084/8)
supported mips.

Now that we have `crt-static` target-feature (the user can choose
dynamic link for musl targets), and libunwind
[6.0](https://github.com/llvm-mirror/libunwind/commits/release_60) add
support to mips, we do not need to assume dynamic linking.
2018-01-22 16:14:51 -02:00
Fenrir
01059b9454 Match libunwind's EABI selection with libpanic_unwind 2018-01-19 02:26:03 -07:00
Ed Schouten
304a7b7985 Link against -lunwind on CloudABI.
CloudABI makes use of LLVM's libunwind to do stack unwinding. It is
installed under the name libunwind.a.
2017-12-26 23:32:42 +01:00
Sébastien Marie
3ef39d3cb6 make OpenBSD to use libc++ instead of (e)stdc++ 2017-11-26 10:08:25 +01:00
Alex Crichton
80ff0f74b0 std: Add a new wasm32-unknown-unknown target
This commit adds a new target to the compiler: wasm32-unknown-unknown. This
target is a reimagining of what it looks like to generate WebAssembly code from
Rust. Instead of using Emscripten which can bring with it a weighty runtime this
instead is a target which uses only the LLVM backend for WebAssembly and a
"custom linker" for now which will hopefully one day be direct calls to lld.

Notable features of this target include:

* There is zero runtime footprint. The target assumes nothing exists other than
  the wasm32 instruction set.
* There is zero toolchain footprint beyond adding the target. No custom linker
  is needed, rustc contains everything.
* Very small wasm modules can be generated directly from Rust code using this
  target.
* Most of the standard library is stubbed out to return an error, but anything
  related to allocation works (aka `HashMap`, `Vec`, etc).
* Naturally, any `#[no_std]` crate should be 100% compatible with this new
  target.

This target is currently somewhat janky due to how linking works. The "linking"
is currently unconditional whole program LTO (aka LLVM is being used as a
linker). Naturally that means compiling programs is pretty slow! Eventually
though this target should have a linker.

This target is also intended to be quite experimental. I'm hoping that this can
act as a catalyst for further experimentation in Rust with WebAssembly. Breaking
changes are very likely to land to this target, so it's not recommended to rely
on it in any critical capacity yet. We'll let you know when it's "production
ready".

---

Currently testing-wise this target is looking pretty good but isn't complete.
I've got almost the entire `run-pass` test suite working with this target (lots
of tests ignored, but many passing as well). The `core` test suite is still
getting LLVM bugs fixed to get that working and will take some time. Relatively
simple programs all seem to work though!

---

It's worth nothing that you may not immediately see the "smallest possible wasm
module" for the input you feed to rustc. For various reasons it's very difficult
to get rid of the final "bloat" in vanilla rustc (again, a real linker should
fix all this). For now what you'll have to do is:

    cargo install --git https://github.com/alexcrichton/wasm-gc
    wasm-gc foo.wasm bar.wasm

And then `bar.wasm` should be the smallest we can get it!

---

In any case for now I'd love feedback on this, particularly on the various
integration points if you've got better ideas of how to approach them!
2017-11-19 21:07:41 -08:00
Tamir Duberstein
b3f50caee0
*: remove crate_{name,type} attributes
Fixes #41701.
2017-08-25 16:18:21 -04:00
Samuel Holland
dbcaf6c80a Do not assume libunwind.a is available 2017-08-24 11:11:55 -05:00
Samuel Holland
c9645678e8 Update libunwind dependencies for musl
Use libgcc_s when linking dynamically. Convert the static libunwind to
static-nobundle, as libunwind.a is copied from musl_root and available
in the library search path.
2017-08-22 16:24:29 -05:00
Ian Douglas Scott
2fd4663fee
Make backtraces work on Redox, copying Unix implementation 2017-08-03 21:13:44 -07:00
Jessica Hamilton
e1afddc29c Haiku: fix initial platform support 2017-04-22 13:47:36 +12:00
Vadim Chugunov
7c2fc62a47 libgcc_eh may depend on libpthread.
Make sure we link to the static libpthread, so that compiled Rust binaries do not depend on winpthread1.dll.
2017-03-30 16:31:46 -07:00
Vadim Petrochenkov
f2187093f8 Add/remove rerun-if-changed when necessary 2017-03-04 21:38:26 +03:00
Yamakaky
d50e4cc064
Improve backtrace formating while panicking.
- `RUST_BACKTRACE=full` prints all the informations (old behaviour)
- `RUST_BACKTRACE=(0|no)` disables the backtrace.
- `RUST_BACKTRACE=<everything else>` (including `1`) shows a simplified
  backtrace, without the function addresses and with cleaned filenames
  and symbols. Also removes some unneded frames at the beginning and the
  end.

Fixes #37783.

PR is #38165.
2017-02-15 14:24:37 -05:00
Shawn Walker-Salas
ee54be3c9a Add Solaris as recognized ostype
Add cputype recognition for Solaris

Fixes #39729
2017-02-11 20:28:44 -08:00
Alex Crichton
77c3bfa742 std: Remove cfg(cargobuild) annotations
These are all now no longer needed that we've only got rustbuild in tree.
2017-02-06 08:42:54 -08:00
bors
7ac9d337dc Auto merge of #38679 - alexcrichton:always-deny-warnings, r=nrc
Remove not(stage0) from deny(warnings)

Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
2017-01-08 08:22:06 +00:00
Seo Sanghyeon
b14785d3d0 Merge branch 'master' into sparc64 2017-01-01 12:40:10 +09:00
Alex Crichton
a8535ce9d1 std: Don't build docs for misc facade crates
Retain the same behavior as stable.

Closes #38319
2016-12-30 10:00:33 -08:00
Alex Crichton
9b0b5b45db Remove not(stage0) from deny(warnings)
Historically this was done to accommodate bugs in lints, but there hasn't been a
bug in a lint since this feature was added which the warnings affected. Let's
completely purge warnings from all our stages by denying warnings in all stages.
This will also assist in tracking down `stage0` code to be removed whenever
we're updating the bootstrap compiler.
2016-12-29 21:07:20 -08:00
Jonathan A. Kollasch
ecd0ebb86b libunwind: unwinder_private_data_size for sparc64 2016-12-29 21:30:01 -05:00
Ulrik Sverdrup
17cb7bdd83 rustbuild: Add bench = false to std shim crates 2016-11-26 00:26:44 +01:00
Raph Levien
76bac5d33e Add Fuchsia support
Adds support for the x86_64-unknown-fuchsia target, which covers the
Fuchsia operating system.
2016-10-22 07:08:06 -07:00
Brian Anderson
525a798ca6 Rewrite emscripten unwinding to use libcxx 2016-09-30 14:02:55 -07:00
Brian Anderson
b8b50f0eda Preliminary wasm32 support 2016-09-30 14:02:45 -07:00
Jonathan Turner
df52628ee3 Rollup merge of #36727 - kallisti5:master, r=Aatch
Haiku: Initial work at OS support

These changes should be non-invasive to non-Haiku platforms. These patches were hand reworked from Neil's original Rust 1.9.0 patches. I've done some style cleanup and design updates along the way.

There are a few small additional patches to libc, rust-installer and compiler-rt that will be submitted once this one is accepted.

Haiku can be compiled on Linux, and a full gcc cross-compiler with a Haiku target is available, which means bootstrapping should be fairly easy. The patches here have already successfully bootstrapped under our haiku x86_gcc2 architecture. http://rust-on-haiku.com/wiki/PortingRust

I'll be focusing on our more modern gcc5 x86 and x86 architectures for now.

As for support, we're not seeking official support for now. We understand Haiku isn't a top-tier OS choice, however having these patches upstream greatly reduces the amount of patchwork we have to do. Mesa has Haiku code upstream, and we submit patches to keep it going. Mesa doesn't test on Haiku and we're ok with that :-)
2016-09-26 17:29:49 -07:00
Jake Goulding
cc8727e675 Report which required build-time environment variable is not set 2016-09-25 12:18:09 -04:00
Niels Sascha Reedijk
1a6fc8b7b8 Add support for the Haiku operating system on x86 and x86_64 machines
* Hand rebased from Niels original work on 1.9.0
2016-09-25 11:12:23 -05:00
Ulrich Weigand
19b84088d7 Add s390x support
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete.  This includes:

- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
  (only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x

Caveats:

- Resets base cpu to "z10" to bring support in sync with the default
  behaviour of other compilers on the platforms.  (Usually, upstream
  supports all older processors; a distribution build may then chose
  to require a more recent base version.)  (Also, using zEC12 causes
  failures in the valgrind tests since valgrind doesn't fully support
  this CPU yet.)

- z13 vector ABI is not yet supported.  To ensure compatible code
  generation, the -vector feature is passed to LLVM.  Note that this
  means that even when compiling for z13, no vector instructions
  will be used.  In the future, support for the vector ABI should be
  added (this will require common code support for different ABIs
  that need different data_layout strings on the same platform).

- Two test cases are (temporarily) ignored on s390x to allow passing
  the test suite.  The underlying issues still need to be fixed:
  * debuginfo/simd.rs fails because of incorrect debug information.
    This seems to be a LLVM bug (also seen with C code).
  * run-pass/union/union-basic.rs simply seems to be incorrect for
    all big-endian platforms.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-09 22:28:19 +01:00
Jorge Aparicio
43615a03f3 fix cross compilation of std 2016-08-27 01:40:29 -05:00
Jan-Erik Rediger
60599df03b [emscripten] Disable code paths that don't work on emscripten 2016-08-10 16:39:32 +02:00
Jorge Aparicio
f0ec906d18 arm-musl: statically link to libunwind 2016-07-30 15:39:13 -05:00
Vadim Chugunov
6cef93d400 Implement ARM personality routine in Rust.
Remove the `eh_personality_catch` lang item.
Use a simplified version of `cfg_if!` in libunwind.
2016-07-24 01:53:27 -07:00
Vadim Chugunov
051c2d14fb Implement rust_eh_personality in Rust, remove rust_eh_personality_catch.
Well, not quite: ARM EHABI platforms still use the old scheme -- for now.
2016-07-22 14:58:35 -07:00
Srinivas Reddy Thatiparthy
5ed45ef354 run rustfmt on libunwind 2016-05-29 08:47:51 +05:30
Alex Crichton
bb9062a296 rustbuild: Add support for crate tests + doctests
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.

Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.

Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.

A few points of note here are:

* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
  entires for `cargo test` to naturally pick up. This mean that `cargo test -p
  core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
  rust-lang/cargo#860, but we can likely alleviate this restriction once
  workspaces are implemented.

cc #31590
2016-05-12 08:52:20 -07:00
Alex Crichton
0ec321f7b5 rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
2016-05-09 08:22:36 -07:00