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.
I was still having issues with the build system somehow getting confused
as to which set of valgrind headers to use when compiling rt.
This commit moves all the valgrind headers into their own directory
under rt and makes the usage more consistent. The compiler is now passed
the -DNVALGRIND flag when valgrind is not installed, as opposed to
passing -DHAVE_VALGRIND.
We also pass -I src/rt to the compiler when building rt so you can more
easily import what you want. I also cleaned up some erroneous #includes
along the way.
It should be safe to always just import the local valgrind headers and use
them without question. NVALGRIND turns the operations to no-ops when it
is active, and the build and tests run cleanly with or without.
__morestack has to be linked statically. The odd calling convention on x86_64
results in the arguments to __morestack (r10 & r11) being clobbered by the
dynamic linker. gcc links all the __morestack functions statically.
