about summary refs log tree commit diff
path: root/src/libunwind
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-517/+0
2020-07-22build: Remove unnecessary `build = "build.rs"` annotationsVadim Petrochenkov-1/+0
2020-07-15Use an allow-list of platforms that support std.Eric Huss-13/+23
Use a fall-through for no_std targets.
2020-07-15Introduce restricted-std feature.Eric Huss-1/+10
2020-06-24Update libunwind build process for x86_64-fortanix-unknown-sgx targetAdrian Cruceru-0/+36
2020-06-12Rollup merge of #73187 - mati865:bootstrap-cleanup, r=Mark-SimulacrumDylan DPC-6/+0
Remove missed `cfg(bootstrap)`
2020-06-10Remove missed `cfg(bootstrap)`Mateusz Mikuła-6/+0
2020-05-29Make libunwind build hermeticPetr Hosek-0/+2
We want to avoid exporting any symbols from Rust's version of libunwind, and to do so we need to disable visibility annotations to make sure that the -fvisibility=hidden has effect, and also hide global new/delete. This matches the CMake build of libunwind.
2020-05-20rustc_target: Avoid an inappropriate use of `post_link_objects`Vadim Petrochenkov-0/+4
2020-05-05Use -fvisibility=hidden for libunwindPetr Hosek-0/+1
We don't want to export any symbols from Rust's version of libunwind as these may collide with other copies of libunwind e.g. when linking Rust staticlib together C/C++ libraries that have their own version.
2020-04-14Add illumos triplePatrick Mooney-0/+2
Co-Authored-By: Jason King <jason.brian.king@gmail.com> Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
2020-03-05Link to libgcc dynamically on windows-gnu when using dylib cratesAmanieu d'Antras-2/+7
2020-01-06Auto merge of #66899 - msizanoen1:riscv-std, r=alexcrichtonbors-0/+3
Standard library support for riscv64gc-unknown-linux-gnu Add std support for RISC-V 64-bit GNU/Linux and update libc for RISC-V support. r? @alexcrichton
2020-01-01Update the barrier cache during ARM EHABI unwindingAmanieu d'Antras-0/+2
2020-01-01Add support for RISC-V 64-bit GNU/Linuxmsizanoen1-0/+3
2019-12-22Format the worldMark Rousskov-14/+13
2019-11-03Allow foreign exceptions to unwind through Rust codeAmanieu d'Antras-0/+27
2019-10-30Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targetsVojtech Kral-0/+6
If __LITTLE_ENDIAN__ is missing, libunwind assumes big endian and reads unwinding instructions wrong on ARM EHABI. Fix #65765
2019-10-19reduce version number to the smallest required versionStefan Lankes-1/+1
2019-10-18use latest version of libc, remove obsolete codeStefan Lankes-20/+1
2019-10-18remove obsolete codeStefan Lankes-2/+0
2019-10-06redesign of the interface to the unikernel HermitCoreStefan Lankes-0/+21
- the old interface between HermitCore and the Rust Standard Library based on a small C library (newlib) - remove this interface and call directly the unikernel - remove the dependency to the HermitCore linker - use rust-lld as linker
2019-08-16Rollup merge of #63595 - semarie:openbsd-sparc64, r=alexcrichtonMazdak Farrokhzad-1/+5
add sparc64-unknown-openbsd target on OpenBSD, some architectures relies on libc++ (from LLVM) and some others on libestdc++ (particular version of libstdc++ from GCC). sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some years ago). Reintroduce the support of them for openbsd, only for sparc64 arch. Some others architectures on OpenBSD could use them too.
2019-08-15add sparc64-unknown-openbsd targetSébastien Marie-1/+5
on OpenBSD, some architectures relies on libc++ (from LLVM) and some others on libestdc++ (particular version of libstdc++ from GCC). sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some years ago). Reintroduce the support of them for openbsd, only for sparc64 arch. Some others architectures on OpenBSD could use them too.
2019-08-15Use libunwind from llvm-project submodule for musl targetsMarco A L Barbosa-6/+14
2019-08-14Handle cfg(bootstrap) throughoutMark Rousskov-10/+8
2019-08-06redox: convert to target_family unixJeremy Soller-1/+6
2019-07-28Remove lint annotations in specific crates that are already enforced by ↵Vadim Petrochenkov-2/+0
rustbuild Remove some random unnecessary lint `allow`s
2019-07-25libunwind: Use libunwind when targeting UWPHugo Beauzée-Luyssen-1/+3
libgcc's support is using forbidden functions
2019-07-22add support for hexagon-unknown-linux-muslBrian Cain-0/+3
2019-07-07Re-add bootstrap attribute to libunwind for llvm-libunwind featurePetr Hosek-8/+15
This was removed in 8a7dded, but since #62286 hasn't yet made it into beta, this is breaking the build with llvm-libunwind feature enabled. Furthemore, restrict the link attribute to Fuchsia and Linux, matching the logic in build.rs since llvm-libunwind feature isn't yet supported on other systems.
2019-07-04Switch master to 1.38Mark Rousskov-10/+8
2019-07-02Use link attributes on extern "C" blocks with llvm-libuwindPetr Hosek-3/+15
When llvm-libunwind feature is enabled, we need to use link attribute on extern "C" blocks to make sure that symbols provided by LLVM's libunwind that's built as part of Rust's libunwind crate are re-exported. This addresses issue #62088.
2019-06-10std: Remove internal definitions of `cfg_if!` macroAlex Crichton-45/+5
This is duplicated in a few locations throughout the sysroot to work around issues with not exporting a macro in libstd but still wanting it available to sysroot crates to define blocks. Nowadays though we can simply depend on the `cfg-if` crate on crates.io, allowing us to use it from there!
2019-05-20Set -funwind-tables and -fno-exceptions unconditionally for LLVM's libunwindPetr Hosek-5/+2
These are required otherwise libunwind will end up with undefined references to __gxx_personality_v0 which is provided by C++ ABI library and that's undesirable.
2019-05-13Remove bitrig support from rustMarcel Hellwig-2/+0
2019-04-03Support using LLVM's libunwind as the unwinder implementationPetr Hosek-1/+75
This avoids the dependency on host libraries such as libgcc_s which may be undesirable in some deployment environments where these aren't available.
2019-02-10Revert removed #![feature(nll)]Taiki Endo-0/+1
2019-02-04libunwind => 2018Taiki Endo-7/+8
2019-01-26Bump bootstrap compiler to 1.33 betaMark Rousskov-1/+0
2019-01-14Stabilize `cfg_target_vendor`, #29718Jethro Beekman-1/+1
2018-12-25Remove licensesMark Rousskov-40/+0
2018-12-19Adding unwinding support for x86_64_fortanix_unknown_sgx target.Vardhan Thigle-4/+1
2018-12-11std: Depend directly on crates.io cratesAlex Crichton-2/+2
Ever since we added a Cargo-based build system for the compiler the standard library has always been a little special, it's never been able to depend on crates.io crates for runtime dependencies. This has been a result of various limitations, namely that Cargo doesn't understand that crates from crates.io depend on libcore, so Cargo tries to build crates before libcore is finished. I had an idea this afternoon, however, which lifts the strategy from #52919 to directly depend on crates.io crates from the standard library. After all is said and done this removes a whopping three submodules that we need to manage! The basic idea here is that for any crate `std` depends on it adds an *optional* dependency on an empty crate on crates.io, in this case named `rustc-std-workspace-core`. This crate is overridden via `[patch]` in this repository to point to a local crate we write, and *that* has a `path` dependency on libcore. Note that all `no_std` crates also depend on `compiler_builtins`, but if we're not using submodules we can publish `compiler_builtins` to crates.io and all crates can depend on it anyway! The basic strategy then looks like: * The standard library (or some transitive dep) decides to depend on a crate `foo`. * The standard library adds ```toml [dependencies] foo = { version = "0.1", features = ['rustc-dep-of-std'] } ``` * The crate `foo` has an optional dependency on `rustc-std-workspace-core` * The crate `foo` has an optional dependency on `compiler_builtins` * The crate `foo` has a feature `rustc-dep-of-std` which activates these crates and any other necessary infrastructure in the crate. A sample commit for `dlmalloc` [turns out to be quite simple][commit]. After that all `no_std` crates should largely build "as is" and still be publishable on crates.io! Notably they should be able to continue to use stable Rust if necessary, since the `rename-dependency` feature of Cargo is soon stabilizing. As a proof of concept, this commit removes the `dlmalloc`, `libcompiler_builtins`, and `libc` submodules from this repository. Long thorns in our side these are now gone for good and we can directly depend on crates.io! It's hoped that in the long term we can bring in other crates as necessary, but for now this is largely intended to simply make it easier to manage these crates and remove submodules. This should be a transparent non-breaking change for all users, but one possible stickler is that this almost for sure breaks out-of-tree `std`-building tools like `xargo` and `cargo-xbuild`. I think it should be relatively easy to get them working, however, as all that's needed is an entry in the `[patch]` section used to build the standard library. Hopefully we can work with these tools to solve this problem! [commit]: https://github.com/alexcrichton/dlmalloc-rs/commit/28ee12db813a3b650a7c25d1c36d2c17dcb88ae3
2018-12-07Add x86_64-fortanix-unknown-sgx target to libstd and dependenciesJethro Beekman-1/+4
The files src/libstd/sys/sgx/*.rs are mostly copied/adapted from the wasm target. This also updates the dlmalloc submodule to the very latest version.
2018-09-27Bump to 1.31.0 and bootstrap from 1.30 betaJosh Stone-1/+1
2018-09-11stabalize infer outlives requirements (RFC 2093).toidiu-1/+0
Co-authored-by: nikomatsakis
2018-08-29Replace usages of 'bad_style' with 'nonstandard_style'.Corey Farwell-1/+1
`bad_style` is being deprecated in favor of `nonstandard_style`: - https://github.com/rust-lang/rust/issues/41646
2018-08-24check that adding infer-outlives requirement to all crates worksNiko Matsakis-0/+1
2018-08-09[nll] libunwind: enable feature(nll) for bootstrapmemoryruins-0/+1