humenda / rustl4re Goto Github PK

Bindgen gained new options, such as bitfield enums. As these are the prevalent
type in the C sources, it would be advisable to change the code to it.

At the moment, all code is built in release mode. While this is great for
benchmarking, it is certainly suboptimal for development. Therefore, the make
build system should offer an instruction to select the cargo subcommand and the
build type in case of the subcommand "build".

The L4Re build system (BID) currently builds RLIBS and and Rust applications.
However, this means that the rlibs are built over and over again, even though
they just need to be built with the application, not again separately. As BID is
optimised for compiling C-alike software, it is best to hide Rlibs from BID.
Only (Rust) applications and static libraries should be handled by BID. Whether
or not a workspace is used by Rust crate authors should be left as a policy
outside of BID.

The UTCB should be writable or readable, but not both at the same time.
This invariant ensures that data that being read is still valid, except a call
happened in between.
An example: reading an Array is safe, i.e. it's a pointer to the UTCB with a
length. Writing an array is safe as long as the Array is not part of the UTCB.
Differenciating the UTCB in read and write attaches a lifetime to each reference
that exists to it and this one is dropped once the mode is changed.

Hello,
I am currently trying to extract the Rust libraries from this repository for making compilation of binaries for l4re-targets a little bit faster.
Right now, for compiling Rust projects, it is required to build everything of l4re. And this takes quite some time.
So I extracted the libraries for (maybe) compiling l4re-binaries of rust programs directly.
But the linker part of the build seems to hinder this endeavour .
When cargo build finishes the build by calling in the linker, there are a few problems.
(I'll paste the l4-bender command, which is invoked by cargo below)

• The first problem seems to be that all of these paths are interpreted as if they were relative paths, so I had to call this command from the root-directory
• The second following problem seems to be that every single file (and folder) which is mentioned in the command, is interpreted as a .pc-file. Even the last part of the command with -o which should normally define the output file (but here it is used as an input with a .pc ending?)

For compiling I used my "own" rust toolchain:
https://github.com/Steav005/rust/tree/update-l4re-target
Which is based upon atopia's rust toolchain
https://github.com/atopia/rust/tree/update-l4re-target
Which is based upon the recommended toolchain
https://github.com/humenda/rust

For l4-bender, I used the latest snapshot version 21.07

The main problem seems to be that the called l4-bender command is wrong.
With this custom rust toolchain and the 21.07 l4-bender, basic compilation of this repository works flawlessly for the amd64 target. (And I have never seen a .pc-file in this repo's outputs).
I know that this repository uses make and rustc directly for compiling rust libraries/binaries.
But there are to many files to this project for me to grasp the entire compilation process.

How should the correct l4-bender-command be structured ?
Is it even possible to build binaries for l4re externally while static-linking the required libraries?
Are there documents on how to use l4-bender?

The failing l4-bender invocation

"l4-bender" "--" "/home/autumnal/l4rust/target/x86_64-unknown-l4re-uclibc/release/examples/hello-ab8330dafea89441.hello.5qhzz9zp-cgu.0.rcgu.o" "/home/autumnal/l4rust/target/x86_64-unknown-l4re-uclibc/release/examples/hello-ab8330dafea89441.hello.5qhzz9zp-cgu.1.rcgu.o" "/home/autumnal/l4rust/target/x86_64-unknown-l4re-uclibc/release/examples/hello-ab8330dafea89441.hello.5qhzz9zp-cgu.2.rcgu.o" "/home/autumnal/l4rust/target/x86_64-unknown-l4re-uclibc/release/examples/hello-ab8330dafea89441.45jtgf841qjk2mhz.rcgu.o" "-L" "/home/autumnal/l4rust/target/x86_64-unknown-l4re-uclibc/release/deps" "-L" "/home/autumnal/l4rust/target/release/deps" "-L" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib" "--start-group" "-static" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libstd-3603de956c965eaf.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libpanic_abort-601cd4d89ed16e0c.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/liblibc-5b45eb57eb334c25.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libstd_detect-12b236156e9d4b91.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/librustc_demangle-e991672d04416a27.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libhashbrown-819e04a2f2f36d10.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/librustc_std_workspace_alloc-acfa987dd0f2640c.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libunwind-c4492c0f6288c7d7.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libcfg_if-283b1de975de9b2c.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/liblibc-1c300f9078f18581.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/liballoc-77abbfbc930f2f26.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/librustc_std_workspace_core-652b8db2aa5aec18.rlib" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libcore-22323b437be4c831.rlib" "--end-group" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib/libcompiler_builtins-63dc035dd5f6e148.rlib" "-L" "/run/media/autumnal/ssddata/GitRepos/rust/patched/lib/rustlib/x86_64-unknown-l4re-uclibc/lib" "-o" "/home/autumnal/l4rust/target/x86_64-unknown-l4re-uclibc/release/examples/hello-ab8330dafea89441" "--gc-sections" "-O2" "-nostdlib"

The registers struct in l4::utcb currently holds both the current position, as
well as the base ptr of the registers. The base ptr can be efficiently read from
a register and hence the struct field is superfluous.

It is impossible to track UTCB usage during compile-time. Therefore, a small
check should be implemented to allow checking the current UTCB "borrow" state
during runtime. This will allow to make reading/writing the UTCB truly safe, as
concurrency could take place within the same thread, with unwanted effects for
the user.