- remove /usr/include from the include path since the iOS SDK provides the correct version
- `_NSGetEnviron()` is private and not available on iOS
- `.align` without an argument is not allowed with the Apple tools. 2^2 should be the default alignment
- ignore error messages for XCode < 5
- pass include path to libuv
This binds to the appropriate pthreads_* and Windows specific functions
and calls them from Rust. This allows for removal of the C++ support
code for threads.
Fixes#10162
Similarly to the previous commit, libuv is only used by this library, so there's
no need for it to be linked into librustrt and available to all crates by
default.
There are a few reasons that this is a desirable move to take:
1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable
Here's a quick summary of the points of this pull request which make this
possible:
* Two new lang items were introduced: event_loop, and event_loop_factory.
The idea of a "factory" is to define a function which can be called with no
arguments and will return the new event loop as a trait object. This factory
is emitted to the crate map when building an executable. The factory doesn't
have to exist, and when it doesn't then an empty slot is in the crate map and
a basic event loop with no I/O support is provided to the runtime.
* When building an executable, then the rustuv crate will be linked by default
(providing a default implementation of the event loop) via a similar method to
injecting a dependency on libstd. This is currently the only location where
the rustuv crate is ever linked.
* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
implicitly linking to rustuv by default
Closes#5019
This drops more of the old C++ runtime to rather be written in rust. A few
features were lost along the way, but hopefully not too many. The main loss is
that there are no longer backtraces associated with allocations (rust doesn't
have a way of acquiring those just yet). Other than that though, I believe that
the rest of the debugging utilities made their way over into rust.
Closes#8704
This commit re-introduces the functionality of __morestack in a way that it was
not originally anticipated. Rust does not currently have segmented stacks,
rather just large stack segments. We do not detect when these stack segments are
overrun currently, but this commit leverages __morestack in order to check this.
This commit purges a lot of the old __morestack and stack limit C++
functionality, migrating the necessary chunks to rust. The stack limit is now
entirely maintained in rust, and the "main logic bits" of __morestack are now
also implemented in rust as well.
I put my best effort into validating that this currently builds and runs successfully on osx and linux 32/64 bit, but I was unable to get this working on windows. We never did have unwinding through __morestack frames, and although I tried poking at it for a bit, I was unable to understand why we don't get unwinding right now.
A focus of this commit is to implement as much of the logic in rust as possible. This involved some liberal usage of `no_split_stack` in various locations, along with some use of the `asm!` macro (scary). I modified a bit of C++ to stop calling `record_sp_limit` because this is no longer defined in C++, rather in rust.
Another consequence of this commit is that `thread_local_storage::{get, set}` must both be flagged with `#[rust_stack]`. I've briefly looked at the implementations on osx/linux/windows to ensure that they're pretty small stacks, and I'm pretty sure that they're definitely less than 20K stacks, so we probably don't have a lot to worry about.
Other things worthy of note:
* The default stack size is now 4MB instead of 2MB. This is so that when we request 2MB to call a C function you don't immediately overflow because you have consumed any stack at all.
* `asm!` is actually pretty cool, maybe we could actually define context switching with it?
* I wanted to add links to the internet about all this jazz of storing information in TLS, but I was only able to find a link for the windows implementation. Otherwise my suggestion is just "disassemble on that arch and see what happens"
* I put my best effort forward on arm/mips to tweak __morestack correctly, we have no ability to test this so an extra set of eyes would be useful on these spots.
* This is all really tricky stuff, so I tried to put as many comments as I thought were necessary, but if anything is still unclear (or I completely forgot to take something into account), I'm willing to write more!
This commit resumes management of the stack boundaries and limits when switching
between tasks. This additionally leverages the __morestack function to run code
on "stack overflow". The current behavior is to abort the process, but this is
probably not the best behavior in the long term (for deails, see the comment I
wrote up in the stack exhaustion routine).
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Closes#9925
This lets the C++ code in the rt handle the (slightly) tricky parts of
random number generation: e.g. error detection/handling, and using the
values of the `#define`d options to the various functions.
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
Because less C++ is better C++!
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
This is a reopening of the libuv-upgrade part of #8645. Hopefully this won't
cause random segfaults all over the place. The windows regression in testing
should also be fixed (it shouldn't build the whole compiler twice).
A notable difference from before is that gyp is now a git submodule instead of
always git-cloned at make time. This allows bundling for releases more easily.
Closes#8850
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.
This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"
Closes#8826
The syntax of the script requires python < 3, and so does our build system so we
can just use CFG_PYTHON to run the script. This prevents build failures where
`python` is actually python3 or later.
There were two main differences with the old libuv and the master version:
1. The uv_last_error function is now gone. The error code returned by each
function is the "last error" so now a UvError is just a wrapper around a
c_int.
2. The repo no longer includes a makefile, and the build system has change.
According to the build directions on joyent/libuv, this now downloads a `gyp`
program into the `libuv/build` directory and builds using that. This
shouldn't add any dependences on autotools or anything like that.
Closes#8407Closes#6567Closes#6315
Apparently the standard --build and --host flags don't actually
_do_ anything. This re-uses the libuv flags, since they are the
same for getting jemalloc to cross-compile
This lets us use #ifdefs to determine which stage of the build we happen
to be in, which is useful in the event we need to make changes to rustrt
that are incompatible with the code generated by stage0.
This should help pave the way to completing #6575, which will likely
require changes to type signatures for spawn_fn & glue_fn in rustrt.
It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.
- thanks to work in libuv's upstream, we can call libuv's Makefile directly
with parameters, instead of descending in gyp-uv madness and generating
our own.
Safe points are exported in a per-module list via the crate map. A C
runtime call walks the crate map at startup and aggregates the list of
safe points for the program.
Currently the GC doesn't actually deallocate memory on malloc and
free. Adding the GC at this stage is primarily of testing value.
The GC does attempt to clean up exchange heap and stack-allocated
resource on failure.
A result of this patch is that the user now needs to be careful about
what code they write in destructors, because the GC and/or failure
cleanup may need to call destructors. Specifically, calls to malloc
are considered unsafe and may result in infinite loops or segfaults.
This just moves the responsibility for joining with scheduler threads
off to a worker thread. This will be needed when we allow tasks to be
scheduled on the main thread.
rust_sched_launcher is actually responsible for setting up the thread and
starting the loop. There will be other implementations that do not actually
set up a new thread, in order to support scheduling tasks on the main OS
thread.
