about summary refs log tree commit diff
path: root/src/libpanic_unwind
AgeCommit message (Collapse)AuthorLines
2018-04-13std: Minimize size of panicking on wasmAlex Crichton-5/+7
This commit applies a few code size optimizations for the wasm target to the standard library, namely around panics. We notably know that in most configurations it's impossible for us to print anything in wasm32-unknown-unknown so we can skip larger portions of panicking that are otherwise simply informative. This allows us to get quite a nice size reduction. Finally we can also tweak where the allocation happens for the `Box<Any>` that we panic with. By only allocating once unwinding starts we can reduce the size of a panicking wasm module from 44k to 350 bytes.
2018-04-08Move deny(warnings) into rustbuildMark Simulacrum-1/+0
This permits easier iteration without having to worry about warnings being denied. Fixes #49517
2018-04-07Auto merge of #49661 - alexcrichton:bump-bootstrap, r=nikomatsakisbors-12/+6
Bump the bootstrap compiler to 1.26.0 beta Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language features!
2018-04-07Inject the `compiler_builtins` crate whenever the `core` crate is injectedOliver Schneider-0/+1
2018-04-05Bump the bootstrap compiler to 1.26.0 betaAlex Crichton-12/+6
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language features!
2018-02-20make `#[unwind]` attribute specify expectations more clearlyNiko Matsakis-6/+12
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-01-04Make libpanic_unwind build on CloudABI.Ed Schouten-0/+1
CloudABI uses LLVM's libunwind for stack unwinding. There was a small bug that went by unnoticed, namely that it was not built with -fno-rtti. This caused it to (indirectly) depend on the entire C++ runtime. Now that that issue has been resolved, it is also perfectly fine to make use of this library for programming languages other than C++.
2017-11-19std: Add a new wasm32-unknown-unknown targetAlex Crichton-3/+34
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-08-27Add missing dependency for WindowsTatsuyuki Ishi-1/+4
2017-08-25*: remove crate_{name,type} attributesTamir Duberstein-2/+0
Fixes #41701.
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-1/+1
Like #43008 (f668999), but _much more aggressive_.
2017-06-08std: Avoid panics in rust_eh_personalityAlex Crichton-30/+48
This commit removes a few calls to panic and/or assert in `rust_eh_personality`. This function definitely can't itself panic (that'd probably segfault or do something else weird) and I was also noticing that a `pub extern fn foo() {}` cdylib was abnormally large. Turns out all that size was the panicking machinery brought in by the personality function! The change here is to return a `Result` internally so we can bubble up the fatal error, eventually translating to the appropriate error code for the libunwind ABI.
2017-05-06Fix definitions of ULONG_PTRJoshua Sheard-2/+2
2017-02-06std: Remove cfg(cargobuild) annotationsAlex Crichton-4/+0
These are all now no longer needed that we've only got rustbuild in tree.
2017-01-08Auto merge of #38679 - alexcrichton:always-deny-warnings, r=nrcbors-1/+1
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-01Merge branch 'master' into sparc64Seo Sanghyeon-0/+1
2016-12-30std: Don't build docs for misc facade cratesAlex Crichton-0/+1
Retain the same behavior as stable. Closes #38319
2016-12-29Remove not(stage0) from deny(warnings)Alex Crichton-1/+1
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-29libpanic_unwind: UNWIND_DATA_REG for sparc64Jonathan A. Kollasch-0/+3
2016-12-12Merge branch 'master' into redoxJeremy Soller-0/+1
2016-11-26rustbuild: Add bench = false to std shim cratesUlrik Sverdrup-0/+1
2016-11-10Merge branch 'master' into redoxJeremy Soller-1/+1
2016-11-10Fixes for stdio and processes on RedoxJeremy Soller-0/+1
2016-11-07Remove mention of mipsel target_archWang Xuerui-1/+1
The `mipsel` `target_arch` was introduced with the initial MIPSel support (rust-lang/rust@82ec1aef293ddc5c6373bd7f5ec323fafbdf7901), but was subsequently removed with implementation of the Flexible Target Specification (Rust RFC 0131, rust-lang/rust@3a8f4ec32a80d372db2d02c76acba0276c4effd0). This is the only remaining instance in rustc. All others are in the libc repo, and are fixed in rust-lang/libc@b3676593f6930c32d947c59e210789bbfcb30960.
2016-10-18run rustfmt on libpanic_unwindSrinivas Reddy Thatiparthy-21/+20
2016-10-08Rollup merge of #37031 - fitzgen:typo-in-gcc-rs-comment, r=alexcrichtonManish Goregaokar-1/+1
Fix a typo in a comment describing gcc.rs's eh_frame_registry module s/reigster/register/ r? @alexcrichton
2016-10-07Fix a typo in a comment describing gcc.rs's eh_frame_registry moduleNick Fitzgerald-1/+1
s/reigster/register/
2016-10-07Use workspaces and switch to a single Cargo.lock.Ahmed Charles-36/+0
This involves hacking the code used to run cargo test on various packages, because it reads Cargo.lock to determine which packages should be tested. This change implements a blacklist, since that will catch new crates when they are added in the future.
2016-09-30Document emscripten's unwind impl and remove unused functionBrian Anderson-6/+8
2016-09-30Rewrite emscripten unwinding to use libcxxBrian Anderson-11/+92
2016-09-30Preliminary wasm32 supportBrian Anderson-0/+4
2016-09-30Patch panic_unwind to compile, but this is surely brokenJan-Erik Rediger-0/+6
2016-09-09Add s390x supportUlrich Weigand-0/+3
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-09Issue deprecation warnings for safe accesses to extern staticsVadim Petrochenkov-2/+2
2016-08-27fix cross compilation of stdJorge Aparicio-1/+1
2016-08-19Remove old stage0 compatibilityBrian Anderson-39/+0
2016-07-29Auto merge of #35032 - vadimcn:rusty-ehabi, r=alexcrichtonbors-112/+160
Implement ARM personality routine in Rust. Remove the `eh_personality_catch` lang item. Use a simplified version of `cfg_if!` in libunwind. Closes #34786
2016-07-26Fix typosVadim Chugunov-1/+1
2016-07-25Looser LSDA parsingVadim Chugunov-4/+3
2016-07-24Implement ARM personality routine in Rust.Vadim Chugunov-112/+160
Remove the `eh_personality_catch` lang item. Use a simplified version of `cfg_if!` in libunwind.
2016-07-22Implement rust_eh_personality in Rust, remove rust_eh_personality_catch.Vadim Chugunov-134/+158
Well, not quite: ARM EHABI platforms still use the old scheme -- for now.
2016-07-12Use `ptr::{null, null_mut}` instead of `0 as *{const, mut}`Tobias Bucher-2/+4
2016-06-05run rustfmt on libpanic_unwind folderSrinivas Reddy Thatiparthy-190/+155
2016-05-31mk: Prepare for a new stage0 compilerAlex Crichton-11/+3
This commit prepares the source for a new stage0 compiler, the 1.10.0 beta compiler. These artifacts are hot off the bots and should be ready to go.
2016-05-12rustbuild: Add support for crate tests + doctestsAlex Crichton-0/+1
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-09rustc: Use C++ personalities on MSVCAlex Crichton-76/+257
Currently the compiler has two relatively critical bugs in the implementation of MSVC unwinding: * #33112 - faults like segfaults and illegal instructions will run destructors in Rust, meaning we keep running code after a super-fatal exception has happened. * #33116 - When compiling with LTO plus `-Z no-landing-pads` (or `-C panic=abort` with the previous commit) LLVM won't remove all `invoke` instructions, meaning that some landing pads stick around and cleanups may be run due to the previous bug. These both stem from the flavor of "personality function" that Rust uses for unwinding on MSVC. On 32-bit this is `_except_handler3` and on 64-bit this is `__C_specific_handler`, but they both essentially are the "most generic" personality functions for catching exceptions and running cleanups. That is, thse two personalities will run cleanups for all exceptions unconditionally, so when we use them we run cleanups for **all SEH exceptions** (include things like segfaults). Note that this also explains why LLVM won't optimize away `invoke` instructions. These functions can legitimately still unwind (the `nounwind` attribute only seems to apply to "C++ exception-like unwining"). Also note that the standard library only *catches* Rust exceptions, not others like segfaults and illegal instructions. LLVM has support for another personality, `__CxxFrameHandler3`, which does not run cleanups for general exceptions, only C++ exceptions thrown by `_CxxThrowException`. This essentially ideally matches our use case, so this commit moves us over to using this well-known personality function as well as exception-throwing function. This doesn't *seem* to pull in any extra runtime dependencies just yet, but if it does we can perhaps try to work out how to implement more of it in Rust rather than relying on MSVCRT runtime bits. More details about how this is actually implemented can be found in the changes itself, but this... Closes #33112 Closes #33116
2016-05-09rustc: Implement custom panic runtimesAlex Crichton-0/+1133
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).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 13:37:31 +0000