https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2020-08-30T15:45:07+00:00 2020-08-30T15:45:07+00:00 mark markm@cs.wisc.edu 2020-08-28T03:58:48+00:00 urn:sha1:9e5f7d5631b8f4009ac1c693e585d4b7108d4275 2020-05-04T11:08:35+00:00 Sam Elliott selliott@lowrisc.org 2020-05-04T11:08:35+00:00 urn:sha1:cda994633ee109639b9c4c12c20e2aacb6a879cd When panic != unwind, `nounwind` is added to all functions for a target. This can cause issues when a panic happens with RUST_BACKTRACE=1, as there needs to be a way to reconstruct the backtrace. There are three possible sources of this information: forcing frame pointers (for which an option exists already), debug info (for which an option exists), or unwind tables. Especially for embedded devices, forcing frame pointers can have code size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads). In code, it can be the case that debug info is not kept, so it is useful to provide this third option, unwind tables, that users can use to reconstruct the call stack. Reconstructing this stack is harder than with frame pointers, but it is still possible. This commit adds a compiler option which allows a user to force the addition of unwind tables. Unwind tables cannot be disabled on targets that require them for correctness, or when using `-C panic=unwind`. 2020-03-30T05:19:55+00:00 Mazdak Farrokhzad twingoow@gmail.com 2020-03-29T15:19:48+00:00 urn:sha1:1ccb0b4a020cac07a9772d0da722869096a46cef 2020-03-30T05:16:56+00:00 Mazdak Farrokhzad twingoow@gmail.com 2020-03-29T14:41:09+00:00 urn:sha1:0cb9e36090fcaa9243b866a61044018a9e6b8c41 2020-03-11T07:10:21+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2020-03-10T00:00:00+00:00 urn:sha1:1106579c780ceafc3493be0c3f43f821920554ae Changed functions: * LLVMRustGetOrInsertFunction * LLVMRustGetNamedValue * LLVMRustBuildCall (removed unused name argument) * LLVMRustInlineAsm * LLVMRustInlineAsmVerify * LLVMRustAppendModuleInlineAsm 2020-02-29T18:59:09+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2020-02-29T17:37:32+00:00 urn:sha1:e08c279eacfd37b8921378c8bd4ef8b8dc9bd176 2019-12-22T22:42:47+00:00 Mark Rousskov mark.simulacrum@gmail.com 2019-12-22T22:42:04+00:00 urn:sha1:a06baa56b95674fc626b3c3fd680d6a65357fe60 2019-12-11T14:50:11+00:00 Alex Crichton alex@alexcrichton.com 2019-10-22T15:51:35+00:00 urn:sha1:7f23e6e8d7479d8a430e007fab9b195b7ea0d261 This commit builds on #65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported. 2019-10-27T16:05:57+00:00 Mazdak Farrokhzad twingoow@gmail.com 2019-10-09T14:47:38+00:00 urn:sha1:fb12c708521d66b1f727ad4c1ec752a78799980d This is done by moving some data definitions to syntax::expand. 2019-10-16T08:59:53+00:00 Mazdak Farrokhzad twingoow@gmail.com 2019-10-16T08:59:30+00:00 urn:sha1:d420d719c4c44c3c6d02b5fafba4f2cf5e837dba