Throwing in upcall_fail ends up running lots of code in the red zone. To avoid
it we have the personality function figure out which stack it's on and switch
as needed.
Shims need to play with the stack limit, upcalls don't. Only one upcall,
upcall_fail is allowed to catch, and we need a find a way to get rid of that
catch as well because it results in _Unwind_Resume running off the end of the
Rust stack.
We should probalby warn when defining a method foo on {foo: int} etc.
This should reduce the amount of useless typevars that are allocated.
Issue #1227
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.
Indexes are listed in ~/.cargo/sources.json and ~/.cargo/local-sources.json, the
former of which is stored in the rust source tree in src/cargo. Each entry in
either of these files is a source, which is a dictionary with (currently) a
single key, "url". The supplied url should point to a json list, each element of
which should be a dictionary with four keys: "name", "uuid", "url", and
"method". The name and uuid serve to identify the package; the method describes
how to fetch the package; the url describes where to fetch it from. Currently
supported methods are "git", "http", and "file".
Signed-off-by: Elly Jones <elly@leptoquark.net>
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.
I think it should undefined to have multiple modules that link in the same
library, but provide different link arguments. Unfortunately we don't track
link_args by module -- they are just appended as discovered into the crate
store -- but for now, it should be an error to provide link_args on a module
that's already been included (with or without link_args).
