Johnathan Van Why
Johnathan Van Why
> I personally would be okay with just removing all of the debug implementation as I don't use them for debugging and we shouldn't use them in production code at...
> I just found out that we are not the only ones wanting a more lightweight formatting in Rust: https://twitter.com/japaric_io/status/1196203591737991168 > > There is now the `ufmt` crate, streamlining a...
It's very hard to understand what `cargo` does by reading its code, so I cloned it and added print statements to the file lock and unlock functions. I've determined that:...
So the current status is that building for different platforms with the same target triple causes races.
Regarding the README, it needs a rewrite: #398. I haven't gotten around to implementing allocation support yet. I was planning to add a separate memory allocation crate, and add a...
The memory layout for a `libtock_runtime`-based process is defined in [libtock_layout.ld](https://github.com/tock/libtock-rs/blob/master/runtime/libtock_layout.ld). It matches this diagram: https://github.com/tock/tock/blob/master/doc/processram.png I recommend the following steps: 1. Add a function to `libtock_runtime` that provides the...
There are at least two problems getting in the way of `rustc` support for ROPI-RWPI: 1. LLVM's ROPI-RWPI implementation does not move `.rodata` values that are relocated into `.data`, which...
Static linking works as of #64 ; making ROPI-RWPI relocation work correctly is a larger problem that'll take longer to solve.
> Was it considered to ignore the ROPI/RWPI approach, and instead rely on relocations and fix them up using a linker? That step could even take place in tockloader, while...
> Thanks. I just realized that static linking also makes the RAM address fixed, which is rather suboptimal when applications are meant to be able to be loaded in any...