Skip to content
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

Rewrite libudirt in Rust #5

Open
mcnulty opened this issue Sep 25, 2023 · 0 comments
Open

Rewrite libudirt in Rust #5

mcnulty opened this issue Sep 25, 2023 · 0 comments

Comments

@mcnulty
Copy link
Member

mcnulty commented Sep 25, 2023

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:

  • Use c2rust to convert libudirt to Rust
    • This would be a starting point and would need a lot of rework to be idiomatic Rust
    • This may or may not target #[no_std] so that may require more work
  • Use iced instead of udis86
  • Use serde + ciborium instead of libcbor

Some downsides:

  • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant