Some work on freestanding Rust: foreign calls, exchange allocator

[brson]

r? @graydon

This is some initial work on freestanding Rust I've had sitting around. It is needed to write scheduler code in Rust.

It does two major things:

1. Calls to upcall_call_on_c_stack/upcall_call_on_rust_stack will first check whether they are running in 'task context', i.e. if they can find the task pointer. If not they will call the function directly without switching stacks. This allows the same foreign function declarations to work either with or without the runtime.
2. It rewrites the exchange allocator so that it works outside of task context so that any Rust code can allocate owned types.

My intent was to write the exchange heap allocator in Rust but after I did so I noticed that there are still a number of C++ utility functions that make exchange heap allocations. As a result there is one written in Rust and one written in C++ (that both just use malloc), and they share a global atomic reference count of allocations. This change loses some of the debugging facilities provided by the existing memory_region allocator. It may be that this iteration of the allocator is insufficient, but I'd like your opinion.

[graydon]

r+ overall, I trust you have a plan here. I'm confused about a number of elements and left a few line comments but don't let me slow you down. I'm fine with the multiplication of wonky allocators as stopgap measures; we're going to have a much more serious allocator -- or set of allocators -- at some point this year, this is all transitional.

For my own understanding: I realize bug #4457 uses the term "without a runtime", but to be precise: "without a runtime" is used here as an exact synonym for "running in a thread that hasn't put a task pointer in TLS", correct? There are enough moving pieces here that I think it pays to be precise in what we're talking about / doing.

(The potential additional state of "has a task pointer in TLS but it's not accurate due to someone switching stacks without updating TLS" is ... one of the reasons I'd like to move to pulling the task pointer out of (sp & ~0xfff) + 0x1000 or such)

[brson]

@graydon Yes that is what I mean here by 'without a runtime'. Lately I think of 'the runtime' and 'the scheduler' as the same thing. This isn't going to get us to a true freestanding rust any time soon, but I think what people mostly want (and what we need) is to execute rust code without the scheduler. I hope to make it clear which parts of core rely on the scheduler and which don't.

Regarding the issue of updating TLS, I don't yet understand the solution you are proposing and how it relates to our current implementation. Let's talk about it on IRC some time.