Giter Club home page Giter Club logo

rustl4re's Introduction

Rust On L4Re

This repository contains a patched version of the L4Re microkernel operating system that includes support for Rust client and server applications. At its heart, the L4Rust libraries enable a Rust developer to efficiently develop Rust clients and servers running on top of a highly configurable, secure and performant OS. Rust services and clients can communicate without adaptation with C++ server and clients from L4Re.

Suggestions, criticism and everything else is welcome, contact me on IRC as Moomoc in the Mozilla, Freenode or OFTC network.

L4Re Setup

This is better explained in RL4Re's README, but in short you need (GNU) make, gcc, libgcc, bison and flex. Execute make setup and make -j4 afterwards. If compilation aborts with "failed to build l4linux", you successfully build everything except l4linux which isn't required.

This L4Re snapshot needs to reside in a path without any spaces, thanks to Makes inability to treat those appropriately. Enter the L4Re source tree root and type make ssetup to choose the build target. Then type make, followed by half a dozen tea breaks.

Now you need to configure the object directory for your build. Open a new file called obj/l4/amd64/conf/Makeconf.local and specify the object directory; substitute amd64 through the chosen architecture. Assuming you are on x86_64 (AKA amd64) and the source tree is below /home/user/l4re, the content might look like this:

OBJ_BASE=/home/USER/rustl4re/obj/l4/amd64

Rust Compilation

Rust doesn't ship binary versions of the cross-compiled std crate. There is also a minor deficiency in passing linker arguments containing spaces, so you need a slightly patched Rust compiler yourself. Grab the source from https://github.com/humenda/rust and follow these steps:

  • Create a file config.toml in the repository root with this content:

    [llvm]
    optimize = true
    [build]
    build = "x86_64-unknown-linux-gnu"    # defaults to your host platform
    target = ["x86_64-unknown-l4re-uclibc"] # defaults to just the build triple
    docs = false
    [install]
    prefix = '/your/preferred/path'
    [rust]
    optimize = true
    use-jemalloc = false
    backtrace = false
    
    You should adjust both prefix and potentially the `build =`-line, if you
    don't use Linux on a `x86_64` machine.
    
  • For building Rust with std:

    $ python3 x.py --host=x86_64-unknown-linux-gnu --target=x86_64-unknown-l4re-uclibc

Then you can proceed to building the L4Re source tree, see the linked instructions above or with hacking, see below.

Branch setup

The branch upstream contains the original L4Re snapshot. The patches to the build system BID are in bid_changes which is rebased on upstream if a new version comes out. master is based on bid_changes and contains all the library implementation of l4rust and a few sample applications, see pkg/l4rust and pkg/oxisamples.

The branch bench contains some hackish benchmarking applications. These are are not guaranteed to run in all environments, patches welcome.

rustl4re's People

Contributors

atopia avatar humenda avatar sevenautumns avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

rustl4re's Issues

[BID] Make RLIBs invisible

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.

l4::utcb::Registers: implement modes

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.

l4::Registers: void *base pointer

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.

Implement facility to track UTCB usage

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.

l4-bender usage with Rust

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"

Allow different subcommands and build types

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".

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.