Like I commented in #2043, I can't reproduce the weirdness from #1388 on either mac or linux (x84_64) and pushing to try gives all green.
That's 128 less bytes to have to keep in the stack for every call to __morestack.
Many changes to code structure are included:
- removed TIME_SLICE_IN_MS
- removed sychronized_indexed_list
- removed region_owned
- kernel_owned move to kernel.h, task_owned moved to task.h
- global configs moved to rust_globals.h
- changed #pragma once to standard guard in rust_upcall.h
- got rid of memory.h
I haven't thought too deeply about this, but I think I was telling the
unwinder to use the stack pointer for the wrong frame when unwinding. Not sure
how that could have worked at all, but this results in the correct alignment
for cleanups.
The DW_CFA_val_offset_sf instruction doesn't seem to work on mac,
even after implementing it in the llvm-mc assembler, so now
I'm looking for a different way to communicate the stack pointer
adjustment to the unwinder.
The DW_CFA_val_offset_sf instruction doesn't seem to work on mac,
even after implementing it in the llvm-mc assembler, so now
I'm looking for a different way to communicate the stack pointer
adjustment to the unwinder.
When unwinding through __morestack the stack limit in the TLS is invalidated
and must be reset. Instead of actually landing at __morestack we're
just going to make all our Rust landing pads call upcall_reset_stack_limit,
which will find the stack segment that corresponds to the current stack
pointer and put the limit in the TLS.
Also massively expand the stack segment red zone to make more room for the
dynamic linker. Will fix in the future.
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.
