You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be interesting to explore rewriting libudirt as a #[no_std] crate, built as a dylib for a variety of reasons:
udis86 is no longer being maintained. The library is feature complete but the build system has started to ossify so that will continue to be an issue with building libudirt going forward.
Rust supports packaging of an allocator that would be exclusive to libudirt with support for doing so in the standard library. Right now, a version of dlmalloc is built as part of libudirt whereas using an off the shelf allocator provides more flexibility.
Contributing to udi would be easier because you would only need a Rust toolchain.
Having Rust's safety guarantees in the runtime would significantly increase the stability of UDI as a whole
I'm personally way more productive in Rust than C so it could significantly decrease the time to implement new features
Writing multi-platform code a far easier in Rust than C
In terms of how to approach this work, some possible steps:
There does not appear to be a widely used ARM disassembler written in Rust. Might not be too difficult to implement but would be something that would need to be implemented first before adding ARM support.
It would delay development of other aspects of UDI significantly
The text was updated successfully, but these errors were encountered:
It would be interesting to explore rewriting libudirt as a
#[no_std]
crate, built as a dylib for a variety of reasons:In terms of how to approach this work, some possible steps:
#[no_std]
so that may require more workSome downsides:
The text was updated successfully, but these errors were encountered: