-
Notifications
You must be signed in to change notification settings - Fork 27
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
Switch to cr.h? #16
Comments
Awesome! Great work |
@Neopallium Hi, great work with that, looks amazing! If you think any of your changes to cr.h would be better upstream, please do open PRs and we can get it sorted out to help making cr-rs a reality faster! |
FYI, the Missing:
@fungos Thanks for the great work in |
Publish the first version of @fungos Rollback worked after a crash (de-reference null pointer). Be reloading a new version seems causes a setjmp/longjmp loop. Also saw some invalid reads in the data section code in Might have to catch crashes in the Rust setjmp/longjmp might not work well with Rust. I remember reading that Lua VM bindings were having issues with handling Lua errors, which uses setjmp/longjmp too. |
FYI, fixed the rollback + reload issue. Also Rust panics are caught and trigger a rollback. It seems setjmp/longjmp can work to recover from segfaults from unsafe Rust code, since it doesn't get caught by |
I have created the start of a Rust wrapper for
cr.h
:https://github.com/Neopallium/cr-rs
Right now I am planning on a host-side and guest-side sys crates, since two different libraries need to be crated. Might be able to use features to keep it as one library that can be compiled as either side as needed.
Right now a basic host example compiles and can load the libbasic_guest.so from
cr.h
samples.The only problem I see right now is that
cr.h
doesn't provide access to the library handle. The cr-sys crate could patch in a function to return the library handle.The text was updated successfully, but these errors were encountered: