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 = 0x6FAULT HANDLER: rip = 0x43ce7cFAULT HANDLER: rsp = 0x120c0cd0FAULT HANDLER: rax = 0x2FAULT HANDLER: rbx = 0FAULT HANDLER: rcx = 0x8a7058FAULT HANDLER: rdx = 0x1FAULT HANDLER: rsi = 0x2FAULT HANDLER: rdi = 0x8FAULT HANDLER: r8 = 0x2FAULT HANDLER: r9 = 0x15FAULT HANDLER: r10 = 0x12014000FAULT HANDLER: r11 = 0x1206c810FAULT HANDLER: r12 = 0x6FAULT HANDLER: r13 = 0x12069f50FAULT HANDLER: r14 = 0x120c0ee0FAULT HANDLER: r15 = 0x120c0ec0FAULT HANDLER: rflags = 0x10206FAULT HANDLER: tls_base = 0x9d6b10FAULT HANDLER: memory map:FAULT HANDLER: +-- 0x0000000000a4ffff --FAULT HANDLER: | guard pageFAULT HANDLER: +-- 0x0000000000a4f000 --FAULT HANDLER: | stackFAULT HANDLER: +-- 0x0000000000a4b000 --FAULT HANDLER: | guard pageFAULT HANDLER: +-- 0x0000000000a4a000 --FAULT HANDLER: | <undescribed>FAULT HANDLER: +-- 0x0000000000a3dfff --FAULT HANDLER: | guard pageFAULT HANDLER: +-- 0x0000000000a3d000 --FAULT HANDLER: | IPC bufferFAULT HANDLER: +-- 0x0000000000a3c000 --FAULT HANDLER: | guard pageFAULT HANDLER: +-- 0x0000000000a3b000 --FAULT HANDLER: | <undescribed>FAULT HANDLER: +-- 0x0000000000a34fff --FAULT HANDLER: | code and dataFAULT 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]> 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]] > 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]>> 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]>> > 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 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
