I think you need another pointer layer for variables. So:
   #[linkage = "extern_weak"]
    static camkes_buffer: *const*mut u8;

And then another dereference when you assign to it.
I don't know if this is a bug in rust - there is an example of it in a comment on the rust issue I linked in my last email.

Kent.
________________________________________
From: Michal Podhradsky [mpodhradsky@galois.com]
Sent: Friday, August 18, 2017 8:33 AM
To: Mcleod, Kent (Data61, Kensington NSW)
Cc: devel@sel4.systems
Subject: Re: [seL4] rumprun + rust + camkes

Hello Kent,

thanks for your reply. The functions pointers definitely are not prettiest, but if needed a nicer wrapper function or a macro can be added in the rust app.

However, I tried adding a shared buffer (dataport) in the rust app, to emulate the reverse string functionality from the rump_ethernet app.

I add a static pointer to a C array:

    #[linkage = "extern_weak"]
    static camkes_buffer: *mut u8;

and then modify the buffer before sending camkes_ev_emit():

*camkes_buffer.offset(0) = 'a' as u8;
...

But when I run the application, I get this result:

=== calling "hello" main() ===

Hello rust!
Server: Got string:
Server: Buffer[0]=0
Waiting for event!
Got event!
RUST: Buffer: 97

=== main() of "hello" returned 0 ===

Which looks like the memory is not shared, although the connection is established and the interface is exposed.

The changes are summarized here: https://github.com/GaloisInc/camkes/commit/6dd2873fbd58133b798e359cb0ff5f5d62712816

Is there something I am missing?

Regards
Michal


On Thu, Aug 17, 2017 at 6:18 AM, <Kent.Mcleod@data61.csiro.au<mailto:Kent.Mcleod@data61.csiro.au>> wrote:

​Hello Michal,


I haven't found a nice way of linking CAmkES generated symbols against the top level of rumprun apps yet.  By top level I mean the POSIX app that gets linked against syscall layer, and the bottom level is the implementation of the syscall layer including the rump kernel, platform layer code, and camkes generated code.  The two layers are individually compiled and linked separately and both have a main function.   When the layers are combined into the same address space, the main function in the top layer is renamed and it is then linked with the bottom layer (this is done using the rumprun_bake tool).  Symbols are effectively name-spaced so that they don't collide across the two layers.


The CAmkES generated connectors are compiled and linked into the bottom layer.  I don't think it is currently possible to take the generated objects, create a new archive of them and then link the archive into the top layer without ending up with two sets of the same symbols.   Maybe there needs to be a way to mark connections as either top level or bottom level and they will only be linked in once (this would also nicely extend to supporting connectors that directly generate rust instead  of C).


The current way I achieve what you want in the Ethernet app is by marking the symbols  weak in the top layer, the compiler won't complain if they don't exist, and then when the top is combined with the bottom, the symbols are successfully linked.


I managed to get this working with your rust app here:  https://github.com/kent-mcleod/camkes/tree/rustapp

​It isn't pretty, and I hope there is a better way in Rust of marking C foreign functions as weak.  See this discussion here for more info: https://github.com/rust-lang/rust/issues/29603

Rust only allows pointers to be marked as weak which is why the functions in the rust code are declared as function pointers, and then cast to actual functions (yuck).


Kind regards,

Kent



________________________________
From: Devel <devel-bounces@sel4.systems> on behalf of Michal Podhradsky <mpodhradsky@galois.com<mailto:mpodhradsky@galois.com>>
Sent: Wednesday, August 16, 2017 5:04 AM
To: devel@sel4.systems
Subject: [seL4] rumprun + rust + camkes

Hello Kent,

I extended the rumprun+rust example (available in this PR<https://github.com/seL4/camkes/pull/4>) with a simple camkes connection between the rumprum camkes component and a serial server component, as shown below (full code here<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_rust/rumprun_rust.camkes>):

 composition {
     component rumprun_platform_layer rrpl;

     component rumprun_rust hello1;
     RUMPRUN_META_CONNECTION(hello1, rrpl)

     component rumprun hello2;
     RUMPRUN_META_CONNECTION(hello2, rrpl)

     component Server server;

     connection seL4SharedData conn(from hello1.camkes_buffer, to server.buffer);
     connection seL4Notification simpleEvent1(from hello1.camkes_ev, to server.ev);
     connection seL4Notification simpleEvent2(from server.ev1, to hello1.camkes_ev1);
 }

I added a simple rust program<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_rust/components/hellorust/rustest/src/main.rs> (running on rumprun_rust):

fn main() {
 println!("Hello rust!");
 unsafe {
  camkes_ev_emit();
 }
 println!("Waiting for event!");
 unsafe {
camkes_ev1_wait();
 }
 println!("Got event!");

}

#[no_mangle]
extern {
    fn camkes_ev_emit();
    fn camkes_ev1_wait();
}

In order to compile the cargo project, I added a build.rs script<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_rust/components/hellorust/rustest/build.rs> to package the generated camkes object file (camkes.o) into an archite that cargo can link against.

The problem is, that the generated camkes.c file contains its own main function:

int USED main(int argc UNUSED, char *argv[]) {
    assert(argc == 2);
    assert(strcmp(argv[0], "camkes") == 0);

    int thread_id = (int)(uintptr_t)(argv[1]);
    return post_main(thread_id);
}

which collides with the fn main() defined in rust. (I get multiple definition of `main' error).

How is this handled in rumprun_ethernet<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_ethernet/rumprun_ethernet.camkes> example? There is also a main function for the rumpkernel component<https://github.com/GaloisInc/camkes/blob/devel_rust_app/apps/rumprun_ethernet/components/rump_ether/tcp_server.c#L49>, and the main() from camkes, but the compilation process handles this correctly.

Could you point me in the right direction?

Regards
Michal