Oh, it worked that way for a const char* that I tested it with yesterday. I'll try have a look at your app.
Kent ________________________________ From: Michal Podhradsky <[email protected]> Sent: Friday, August 18, 2017 9:03 AM To: Mcleod, Kent (Data61, Kensington NSW) Cc: [email protected] Subject: Re: [seL4] rumprun + rust + camkes Hi Kent, I changed the declaration to: #[linkage = "extern_weak"] static camkes_buffer: *const *mut u8; and **camkes_buffer.offset(0) = 'a' as u8; but now when running the app I get a fault: Hello rust! FAULT HANDLER: data fault from hello1.control (ID 0x1) on address 0x1, pc = 0x43ce7c, fsr = 0x6 FAULT HANDLER: rip = 0x43ce7c FAULT HANDLER: rsp = 0x120c0cd0 FAULT HANDLER: rax = 0x2 FAULT HANDLER: rbx = 0 FAULT HANDLER: rcx = 0x8a7058 FAULT HANDLER: rdx = 0x1 FAULT HANDLER: rsi = 0x2 FAULT HANDLER: rdi = 0x8 FAULT HANDLER: r8 = 0x2 FAULT HANDLER: r9 = 0x15 FAULT HANDLER: r10 = 0x12014000 FAULT HANDLER: r11 = 0x1206c810 FAULT HANDLER: r12 = 0x6 FAULT HANDLER: r13 = 0x12069f50 FAULT HANDLER: r14 = 0x120c0ee0 FAULT HANDLER: r15 = 0x120c0ec0 FAULT HANDLER: rflags = 0x10206 FAULT HANDLER: tls_base = 0x9d6b10 FAULT HANDLER: memory map: FAULT HANDLER: +-- 0x0000000000a4ffff -- FAULT HANDLER: | guard page FAULT HANDLER: +-- 0x0000000000a4f000 -- FAULT HANDLER: | stack FAULT HANDLER: +-- 0x0000000000a4b000 -- FAULT HANDLER: | guard page FAULT HANDLER: +-- 0x0000000000a4a000 -- FAULT HANDLER: | <undescribed> FAULT HANDLER: +-- 0x0000000000a3dfff -- FAULT HANDLER: | guard page FAULT HANDLER: +-- 0x0000000000a3d000 -- FAULT HANDLER: | IPC buffer FAULT HANDLER: +-- 0x0000000000a3c000 -- FAULT HANDLER: | guard page FAULT HANDLER: +-- 0x0000000000a3b000 -- FAULT HANDLER: | <undescribed> FAULT HANDLER: +-- 0x0000000000a34fff -- FAULT HANDLER: | code and data FAULT HANDLER: +-- 0x0000000000400000 -- You mentioned it could be a bug in rust - like it can't properly do a weak link to a C array? Regards M On Thu, Aug 17, 2017 at 3:43 PM, <[email protected]<mailto:[email protected]>> wrote: 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 [[email protected]<mailto:[email protected]>] Sent: Friday, August 18, 2017 8:33 AM To: Mcleod, Kent (Data61, Kensington NSW) Cc: [email protected] 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, <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> 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 <[email protected]> on behalf of Michal Podhradsky <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> Sent: Wednesday, August 16, 2017 5:04 AM To: [email protected] 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<http://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
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
