https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=master 2019-05-26T00:09:45+00:00 2019-05-26T00:09:45+00:00 Alex Crichton alex@alexcrichton.com 2019-05-15T14:30:15+00:00 urn:sha1:d1040fe329a8db99ae0aae47975830a0829d7792 This commit removes all in-tree support for generating backtraces in favor of depending on the `backtrace` crate on crates.io. This resolves a very longstanding piece of duplication where the standard library has long contained the ability to generate a backtrace on panics, but the code was later extracted and duplicated on crates.io with the `backtrace` crate. Since that fork each implementation has seen various improvements one way or another, but typically `backtrace`-the-crate has lagged behind libstd in one way or another. The goal here is to remove this duplication of a fairly critical piece of code and ensure that there's only one source of truth for generating backtraces between the standard library and the crate on crates.io. Recently I've been working to bring the `backtrace` crate on crates.io up to speed with the support in the standard library which includes: * Support for `StackWalkEx` on MSVC to recover inline frames with debuginfo. * Using `libbacktrace` by default on MinGW targets. * Supporting `libbacktrace` on OSX as an option. * Ensuring all the requisite support in `backtrace`-the-crate compiles with `#![no_std]`. * Updating the `libbacktrace` implementation in `backtrace`-the-crate to initialize the global state with the correct filename where necessary. After reviewing the code in libstd the `backtrace` crate should be at exact feature parity with libstd today. The backtraces generated should have the same symbols and same number of frames in general, and there's not known divergence from libstd currently. Note that one major difference between libstd's backtrace support and the `backtrace` crate is that on OSX the crates.io crate enables the `coresymbolication` feature by default. This feature, however, uses private internal APIs that aren't published for OSX. While they provide more accurate backtraces this isn't appropriate for libstd distributed as a binary, so libstd's dependency on the `backtrace` crate explicitly disables this feature and forces OSX to use `libbacktrace` as a symbolication strategy. The long-term goal of this refactoring is to eventually move us towards a world where we can drop `libbacktrace` entirely and simply use Gimli and the surrounding crates for backtrace support. That's still aways off but hopefully will much more easily enabled by having the source of truth for backtraces live in crates.io! Procedurally if we go forward with this I'd like to transfer the `backtrace-rs` crate to the rust-lang GitHub organization as well, but I figured I'd hold off on that until we get closer to merging. 2019-02-27T19:06:15+00:00 Taiki Endo te316e89@gmail.com 2019-02-10T19:23:21+00:00 urn:sha1:93b6d9e086c6910118a57e4332c9448ab550931f 2018-12-31T21:07:28+00:00 John Kåre Alsaker john.kare.alsaker@gmail.com 2018-12-31T20:48:06+00:00 urn:sha1:f4826abf6d04d3c468e37c3e7b670d35030ef0e0 2018-12-26T04:08:33+00:00 Mark Rousskov mark.simulacrum@gmail.com 2018-12-25T15:56:47+00:00 urn:sha1:2a663555ddf36f6b041445894a8c175cd1bc718c 2018-09-04T21:54:37+00:00 Jordan Rhee jordanrh@microsoft.com 2018-06-26T16:44:19+00:00 urn:sha1:f7fa67cea13efdacfc82389f6f592bb4bda86a2e 2018-08-27T17:40:16+00:00 Mark Mansi markm@cs.wisc.edu 2018-08-27T17:14:31+00:00 urn:sha1:6c264d764efc4c43c170d710edd94556e1401bdb 2018-08-16T00:20:13+00:00 Alex Crichton alex@alexcrichton.com 2018-07-16T23:38:56+00:00 urn:sha1:fccc04d3e72bb462cba1b492ba0e2cd4ab2aebec This commit adds the necessary definitions for target specs and such as well as the necessary support in libstd to compile basic `aarch64-pc-windows-msvc` binaries. The target is not currently built on CI, but it can be built locally with: ./configure --target=aarch64-pc-windows-msvc --set rust.lld ./x.py build src/libstd --target aarch64-pc-windows-msvc Currently this fails to build `libtest` due to a linker bug (seemingly in LLD?) which hasn't been investigate yet. Otherwise though with libstd you can build a hello world program (linked with LLD). I've not tried to execute it yet, but it at least links! Full support for this target is still a long road ahead, but this is hopefully a good stepping stone to get started. Points of note about this target are: * Currently defaults to `panic=abort` as support is still landing in LLVM for SEH on AArch64. * Currently defaults to LLD as a linker as I was able to get farther with it than I was with `link.exe` 2018-06-28T21:57:08+00:00 moxian moxian@google.com 2018-06-04T11:00:12+00:00 urn:sha1:be7f619870085121bdd7911aa882c35e70aedb8a 2018-06-28T21:57:03+00:00 moxian moxian@google.com 2018-05-18T12:33:23+00:00 urn:sha1:9d426ac387f2d42c998349c76ac1c2aea044e0ec 2018-06-28T21:56:58+00:00 moxian moxian@google.com 2018-05-18T11:38:50+00:00 urn:sha1:a0b15012a17594566311ea490eda243b6bd9d92b