about summary refs log tree commit diff
path: root/src/libstd/Cargo.toml
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-78/+0
2020-07-24Rollup merge of #72954 - hermitcore:rwlock, r=dtolnayManish Goregaokar-1/+1
revise RwLock for HermitCore - current version is derived from the wasm implementation - increasing the readability of `Condvar` - simplify the interface to the libos
2020-07-23Auto merge of #74613 - Mark-Simulacrum:revert-gimli, r=nnethercotebors-14/+9
Revert libbacktrace -> gimli This reverts 4cbd265c119cb1a5eb92e98d2bb93466f05efa46 028f8d7b85898683b99e05564cd2976c7e0d5b43 13db3cc1e8d2fd4b8e7c74d91002274d7b62801b d7a36d8964c927863faef5d3b42da08f37e5896c (and technically 79673d300915f846726c27b9e1974dc451013ee9 but it's made empty by previous reverts). The current plan is to land this PR as a temporary change, so that we can get a better handle on the regressions introduced by it. Trying to fix/examine them in master is difficult, and we want to be better able to evaluate them without impact to other PRs being landed in the mean time. That said, it is currently *my* belief that gimli, in one form or another, will need to land sometime soon. I think it's quite likely that it may slip a week or two, but I would personally push for re-landing it then "regardless" of the regressions. We should try to focus efforts on understanding and removing as much of the performance impact as possible, as everyone pretty much agrees that it should be quite minimal (and entirely in the linker, basically). r? @nnethercote
2020-07-22build: Remove unnecessary `build = "build.rs"` annotationsVadim Petrochenkov-1/+0
2020-07-22Revert "std: Switch from libbacktrace to gimli"Mark Rousskov-15/+9
This reverts commit 13db3cc1e8d2fd4b8e7c74d91002274d7b62801b.
2020-07-22Revert "std: Fix compilation without backtrace feature"Mark Rousskov-1/+2
This reverts commit 028f8d7b85898683b99e05564cd2976c7e0d5b43.
2020-07-19std: Fix compilation without backtrace featureAlex Crichton-2/+1
This should hopefully handle #74484 but in any case fixes compilation of the standard library without the `backtrace` feature. The need for this feature is somewhat unclear now because the `backtrace` crate should always compile (no more C code!) but we can handle that later if necessary.
2020-07-17std: Switch from libbacktrace to gimliAlex Crichton-9/+15
This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293, #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up.
2020-07-15Move libstd's default feature to libtestAlex Crichton-2/+0
This commit makes it so `std` no longer has a `default` feature, but instead the `test` crate has a `default` feature doing the same thing. The purpose of this commit is to allow Cargo's `-Zbuild-std` command, which could customize the features of the standard library, to handle the `default` feature for libstd. Currently Cargo's `-Zbuild-std` support starts at libtests's manifest as the entry point to the std set of crates.
2020-07-06use latest version of hermit-abiStefan Lankes-1/+1
2020-06-18Ensure std benchmarks get tested.Eric Huss-0/+5
2020-06-14use latest interface to HermitCoreStefan Lankes-1/+1
2020-06-07Enable LVI hardening for x86_64-fortanix-unknown-sgxJethro Beekman-1/+1
2020-05-29Update compiler-builtinsAlex Crichton-1/+1
Pulls in a fix for #72758, more details on the linked issue. [Crate changes included here][changes] [changes]: https://github.com/rust-lang/compiler-builtins/compare/0.1.28...0.1.31
2020-05-17use new interface to initialize CondvarStefan Lankes-1/+1
HermitCore introduce a new interface to intialize conditional variables. Consequently, minor changes are required to support this interface.
2020-04-26use new interface to create threads on HermitCoreStefan Lankes-1/+1
- the new interface allows to define the stack size
2020-04-11Make panic-unwind a default feature for libstdLuca Barbieri-1/+1
x.py sets it unconditionally, so want it for plain "cargo build". We need to load one of the panic runtimes that is in src (vs. pre-built in the compiler's sysroot) to ensure that we don't load libpanic_unwind from the sysroot. That would lead to a load of libcore, also from the sysroot, and create lots of errors about duplicate lang items.
2020-03-30move the definition of thread priorities to hermit-abiStefan Lankes-1/+1
2020-03-30move OS constants to platform crateStefan Lankes-1/+1
2020-03-24Update backtrace crate to 0.3.46Tomasz Miąsko-1/+1
2020-02-10Bump version to backtrace without the headerJane Lusby-1/+1
2020-01-09Remove sanitizer runtime cratesTomasz Miąsko-10/+0
2019-12-03Update the `wasi` crate for `wasm32-wasi`Alex Crichton-1/+1
This commit updates the `wasi` crate used by the standard library which is used to implement most of the functionality of libstd on the `wasm32-wasi` target. This update comes with a brand new crate structure in the `wasi` crate which caused quite a few changes for the wasi target here, but it also comes with a significant change to where the functionality is coming from. The WASI specification is organized into "snapshots" and a new snapshot happened recently, so the WASI APIs themselves have changed since the previous revision. This had only minor impact on the public facing surface area of libstd, only changing on `u32` to a `u64` in an unstable API. The actual source for all of these types and such, however, is now coming from the `wasi_preview_snapshot1` module instead of the `wasi_unstable` module like before. This means that any implementors generating binaries will need to ensure that their embedding environment handles the `wasi_preview_snapshot1` module.
2019-10-25Merge branch 'master' into rusty-hermit, resolve conflictsStefan Lankes-1/+1
2019-10-24Update hashbrown to 0.6.2Alex Crichton-1/+1
Pulls in rust-lang/hashbrown#119 which should be a good improvement for compile times of hashmap-heavy crates.
2019-10-21add aarch64 support for HermitCoreStefan Lankes-1/+1
2019-10-20Merge branch 'master' into rusty-hermitStefan Lankes-1/+1
2019-10-20move interface to the unikernel in the crate hermit-abiStefan Lankes-0/+3
=> simplifies the maintenance of the interface
2019-10-09Implement (HashMap) Entry::insert as per #60142Félix Saparelli-1/+1
2019-09-23Remove unused dependenciesShotaro Yamada-3/+0
2019-09-14rename the crate, not the featureRalf Jung-6/+7
2019-09-14std: always depend on backtrace, but only enable its features on demandRalf Jung-9/+9
2019-09-09Rollup merge of #63806 - mati865:rand, r=alexcrichtonMazdak Farrokhzad-1/+1
Upgrade rand to 0.7 Also upgrades `getrandom` to avoid bug encountered by https://github.com/rust-lang/rust/pull/61393 which bumps libc to `0.2.62`.
2019-09-08Rollup merge of #64152 - cramertj:update-backtrace, r=alexcrichtonMazdak Farrokhzad-1/+1
Use backtrace formatting from the backtrace crate r? @alexcrichton
2019-09-06Upgrade rand to 0.7Mateusz Mikuła-1/+1
2019-09-06Rollup merge of #63676 - newpavlov:wasi, r=alexcrichtonMazdak Farrokhzad-0/+3
Use wasi crate for Core API Blocked by: CraneStation/rust-wasi#5 Blocks: rust-lang/libc#1461 cc @sunfishcode @alexcrichton
2019-09-04Use backtrace formatting from the backtrace crateTaylor Cramer-1/+1
2019-09-03make wasi a target-specific dependencyArtyom Pavlov-1/+3
2019-08-29update to wasi v0.7newpavlov-1/+1
2019-08-28std: Remove the `wasm_syscall` featureAlex Crichton-5/+0
This commit removes the `wasm_syscall` feature from the wasm32-unknown-unknown build of the standard library. This feature was originally intended to allow an opt-in way to interact with the operating system in a posix-like way but it was never stabilized. Nowadays with the advent of the `wasm32-wasi` target that should entirely replace the intentions of the `wasm_syscall` feature.
2019-08-21move cvtnewpavlov-0/+1
2019-08-19std: Update `backtrace` crate dependencyAlex Crichton-1/+1
This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The [included set of changes][changes] for this update mostly includes some gimli-related improvements (not relevant for the standard library) but critically includes a fix for rust-lang/backtrace-rs#230. The standard library will not aqcuire a session-local lock whenever a backtrace is generated on Windows to allow external synchronization with the `backtrace` crate itself, allowing `backtrace` to be safely used while other threads may be panicking. [changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35
2019-08-16Update hashbrown to 0.5.0Simon Sapin-1/+1
2019-07-31Attempt to fix backtrace tests on i686-msvcAlex Crichton-1/+1
Some fixes for i686-msvc and Windows have landed on the `backtrace` crate but hadn't made their way here yet. Let's update that and see if it passes CI.
2019-07-25std: Use native `#[thread_local]` TLS on wasmAlex Crichton-5/+0
This commit moves `thread_local!` on WebAssembly targets to using the `#[thread_local]` attribute in LLVM. This was recently implemented upstream and is [in the process of being documented][dox]. This change only takes affect if modules are compiled with `+atomics` which is currently unstable and a pretty esoteric method of compiling wasm artifacts. This "new power" of the wasm toolchain means that the old `wasm-bindgen-threads` feature of the standard library can be removed since it should now be possible to create a fully functioning threaded wasm module without intrusively dealing with libstd symbols or intrinsics. Yay! [dox]: https://github.com/WebAssembly/tool-conventions/pull/116
2019-07-15Update the stdarch submodulegnzlbg-2/+2
2019-06-14make sure we use cfg-if as a std dependencyRalf Jung-1/+1
2019-06-10std: Remove internal definitions of `cfg_if!` macroAlex Crichton-0/+1
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-06-07Rollup merge of #61603 - Goirad:increase-sgx-heapsize, r=alexcrichtonMazdak Farrokhzad-0/+2
Increases heap size available during testing for SGX PR [61540](https://github.com/rust-lang/rust/pull/61540) causes at least one test to fail when run for the SGX platform due to lack of memory. This PR increases the heapsize available during tests, which is a good thing regardless of the status of that PR.
2019-06-06increase max heapsize available during sgx testsDario Gonzalez-0/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-12 04:50:53 +0000