https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.3.0 2015-07-27T23:21:15+00:00 2015-07-27T23:21:15+00:00 Alex Crichton alex@alexcrichton.com 2015-07-27T23:10:59+00:00 urn:sha1:cf1ff56f3c8a7a55fa38bcdda3907147d25382a2 These aren't really used for anything any more, so there doesn't seem to be much reason to leave them around in the `rt` directory. There was some limiting of threads spawned or tests when run under valgrind, but very little is run under valgrind nowadays so there's also no real use keeping these around. 2015-07-21T23:08:11+00:00 Alex Crichton alex@alexcrichton.com 2015-07-20T20:27:38+00:00 urn:sha1:c35b2bd226736925961ca6853b2ef29e8094cd90 This commit moves the IR files in the distribution, rust_try.ll, rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main distribution. There's a few reasons for this change: * LLVM changes its IR syntax from time to time, so it's very difficult to have these files build across many LLVM versions simultaneously. We'll likely want to retain this ability for quite some time into the future. * The implementation of these files is closely tied to the compiler and runtime itself, so it makes sense to fold it into a location which can do more platform-specific checks for various implementation details (such as MSVC 32 vs 64-bit). * This removes LLVM as a build-time dependency of the standard library. This may end up becoming very useful if we move towards building the standard library with Cargo. In the immediate future, however, this commit should restore compatibility with LLVM 3.5 and 3.6. 2015-07-17T16:18:52+00:00 bors bors@rust-lang.org 2015-07-17T16:18:52+00:00 urn:sha1:d4432b37378ec55450e06799f5344b4b0f4b94e0 LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch. * This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957 which should help us bootstrap farther on 32-bit MSVC targets. * There is better support for writing multiple flavors of archives, allowing us to use the built-in LLVM support instead of the system `ar` on all current platforms of the compiler. * This LLVM has SafeStack support * An [optimization patch](https://github.com/rust-lang/llvm/commit/7cf5e26e18f7d2d8db09c83c76dd727535f281ab) by @pcwalton is included. * A number of other minor test fixes here and there. Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more... 2015-07-17T03:25:51+00:00 Richo Healey richo@psych0tik.net 2015-06-27T21:39:22+00:00 urn:sha1:c55d3f1ba1e78466d2f5703a9e291f4849ddcc94 This is for llvm/cc714e214298cfbf11de65b46de31900d51422cf 2015-07-13T19:13:52+00:00 Akos Kiss akiss@inf.u-szeged.hu 2015-07-13T18:06:04+00:00 urn:sha1:eaee43aeba955e9f6ddb708a01b8e31ce536aece When building for AArch64/Linux, __morestack ends up in the .note.GNU-stack section, which causes missing references for the linker. By using the func/endfunc macros from macros.S we get __morestack right to .text (and a bit more on the side). 2015-07-02T17:45:13+00:00 Alex Crichton alex@alexcrichton.com 2015-06-30T17:28:24+00:00 urn:sha1:3e26e56a79ae33dfc8f2f4d0123b5080fd0a7853 This is currently quite buggy in LLVM from what I can tell, so just disable it entirely. This commit also adds preliminary support, however, to actually target 32-bit MSVC by making sure the `rust_try_msvc_32.ll` file exists and wiring up exceptions to `_except_handler3` instead of `__C_specific_handler` (which doesn't exist on 32-bit). 2015-07-02T17:44:40+00:00 Alex Crichton alex@alexcrichton.com 2015-07-01T04:55:00+00:00 urn:sha1:83ee47b054deb5939be20d7d6ce03ad33d005424 This library has no shims which are actually needed on Windows now, so translate that last easy one into Rust and then don't link it at all on Windows. 2015-06-28T02:25:55+00:00 Richo Healey richo@psych0tik.net 2015-06-26T17:52:53+00:00 urn:sha1:9e58fb85efabadf40ecde8417ad74f7f8898991a 2015-06-25T16:33:15+00:00 Alex Crichton alex@alexcrichton.com 2015-06-19T21:57:06+00:00 urn:sha1:91d799eab0d7f6784fb4366182b5007cf055519d Now that LLVM has been updated, the only remaining roadblock to implementing unwinding for MSVC is to fill out the runtime support in `std::rt::unwind::seh`. This commit does precisely that, fixing up some other bits and pieces along the way: * The `seh` unwinding module now uses `RaiseException` to initiate a panic. * The `rust_try.ll` file was rewritten for MSVC (as it's quite different) and is located at `rust_try_msvc_64.ll`, only included on MSVC builds for now. * The personality function for all landing pads generated by LLVM is hard-wired to `__C_specific_handler` instead of the standard `rust_eh_personality` lang item. This is required to get LLVM to emit SEH unwinding information instead of DWARF unwinding information. This also means that on MSVC the `rust_eh_personality` function is entirely unused (but is defined as it's a lang item). More details about how panicking works on SEH can be found in the `rust_try_msvc_64.ll` or `seh.rs` files, but I'm always open to adding more comments! A key aspect of this PR is missing, however, which is that **unwinding is still turned off by default for MSVC**. There is a [bug in llvm][llvm-bug] which causes optimizations to inline enough landing pads that LLVM chokes. If the compiler is optimized at `-O1` (where inlining isn't enabled) then it can bootstrap with unwinding enabled, but when optimized at `-O2` (inlining is enabled) then it hits a fatal LLVM error. [llvm-bug]: https://llvm.org/bugs/show_bug.cgi?id=23884 2015-06-15T18:56:50+00:00 Steven Walter stevenrwalter@gmail.com 2015-06-15T15:35:47+00:00 urn:sha1:85be7c5f75522265aceb1b186d4f6aaa4014904c This prevents a relocation in the text section. Text relocations are incompatible with hardened kernels. https://github.com/rust-lang/rust/issues/5714