Preventing us from writing beyond our allocations is _what valgrind does_,
so telling valgrind not to let us write to the end of the stack isn't
buying anything.
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.
