Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle application initialisation #4

Open
tsoutsman opened this issue Jul 30, 2022 · 1 comment
Open

Handle application initialisation #4

tsoutsman opened this issue Jul 30, 2022 · 1 comment

Comments

@tsoutsman
Copy link
Member

tsoutsman commented Jul 30, 2022

This should be trivial to do (once libtheseus is sorted out).

We can define a function in std::sys::theseus as follows:

pub unsafe fn __theseus_start(args: Vec<String>) -> isize {
    let argc = args.len();
    let argv = args.as_ptr();

    extern "C" {
        // This function is exported by Rust (and all other language) binaries.
        fn main(argc: isize, argv: *const *const c_char) -> i32;
    }
    
    // Do initialisation.
    let result = unsafe { main(argc as size, argv) };
    // Do cleanup.
    result as isize
}

* This code is untested.

To run a crate we would then run __theseus_start similar to how we currently run main functions exported by applications. The process of finding the section and transmuting it to a function pointer would remain the same.

Hermit does a slightly similar thing.

I believe std::sys::theseus::init is called by the main function exported by binaries. E.g. Hermit's runtime_entry function doesn't initialise the network because it's done in init, which will be called by main.

@kevinaboos
Copy link
Member

yep that seems generally correct. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🛑 Blocked
Development

No branches or pull requests

2 participants