It's all good, that's exactly why I was curious. Your understanding isn't exactly wrong, but basically, all that code relies on there being an 'alloc' and 'free' symbol, so you can swap that out with whatever you want, so you wouldn't actually need to re-write all that code. Also worth noting, there's a clear line between libraries with no allocation (libcore) and the rest, so even if you did throw it all away, you'd still have a chunk of the library.
That interface is super unstable at the moment, and we're working on stabilizing it, but yeah, that's what you'd have to do: write your own allocator and hook it up.
Cool, thanks for the details. I guess I should check who's asking before I respond the next time around. ;) It wasn't clear whether you're pulling my leg or you're interested in deep dive I can't provide. But you can. :] So, question then - wasn't it the case (at one point) that you had dependency on stack unwinding library or some external implementation of TLS? My feeling is that what I read about OS development at that point had also something to do with one of these two. Maybe. Unwind is native to Rust right now and is no longer a problem (on platforms supported), no?
:) It's all good, I was a little bit terse... I should consider that in the future.
We do use gcc's unwinding library, last I recall, but if you're writing an OS, you can implement the language items to do whatever you want, including just abort.
There's no inherent TLS implementation that I'm aware of.
That interface is super unstable at the moment, and we're working on stabilizing it, but yeah, that's what you'd have to do: write your own allocator and hook it up.