[Discussion] any plan to for high level binding?

[flier]

Thank you so much for having people who are still actively maintaining this project!

I'd like to know if you all have any plan to offer high-level bindings?

In fact I did an experimental prototype a couple weeks ago, and if you're looking to start a new project I think I could get involved to contribute code!

[Phantomical]

Wow! That prototype covers quite a bit!

Unfortunately, I don't think I have the bandwidth nor the time to drive the development of a library like that myself. That doesn't mean that I'm not interested in contributing though.

Here's an alternate proposal if you're willing to drive this:

• I'll add you to the team for the rust-xed org
• I'll create a xed repo here for the library (or you can once you have access) - we can start off with your prototype
• You'll be the primary maintainer of the new crate
• I'll help out with the initial push and can serve as a backup/secondary maintainer in the future

Let me know if you're interested. I do think it would be good to have some high-level bindings for XED in the rust ecosystem :)

[flier]

Wow! That prototype covers quite a bit!

In fact, I'm not too satisfied with this prototype, as it's just a simple wrapper around the XED API for learning purposes.

From my viewpoint, the XED API is cumbersome by design, and it looks like the implementation has been refactored a few times. We need a clearer high level binding, not a simple wrapper.

Unfortunately, I don't think I have the bandwidth nor the time to drive the development of a library like that myself. That doesn't mean that I'm not interested in contributing though.

Here's an alternate proposal if you're willing to drive this:

• I'll add you to the team for the rust-xed org
• I'll create a xed repo here for the library (or you can once you have access) - we can start off with your prototype
• You'll be the primary maintainer of the new crate
• I'll help out with the initial push and can serve as a backup/secondary maintainer in the future

Let me know if you're interested. I do think it would be good to have some high-level bindings for XED in the rust ecosystem :)

That's what I'm confused about right now, if we start a new project, what is its contribution to the community.

With the few technical lines I've seen so far

1. Cross-platform binary code generation via IR code based on LLVM, llvm-sys
2. Fine-grained control at the instruction set level for encoding and decoding, XED and zydis
3. Sub-instruction level intermediate representation for data flow analysis, Ghidra P-Code

It looks like our project is positioned closer to zydis.

• Supports all x86 and x86-64 (AMD64) instructions and extensions
• Optimized for high performance we may need enc2 for this
• No dynamic memory allocation ("malloc")
• Thread-safe by design
• Very small file-size overhead compared to other common disassembler libraries
• Trusted by many major open-source projects
• Absolutely no third party dependencies — not even libc
  • Should compile on any platform with a working C11 compiler
  • Tested on Windows, macOS, FreeBSD, Linux and UEFI, both user and kernel mode

Anything else we can add?

[Phantomical]

I think you've got it pretty much right on library positioning: we're making xed easier to use from within rust. The benefits we provide should be the same ones that xed does and I think your list there is accurate. If we can make our hypothetical xed crate easy enough to use (intuitive, well documented, etc.) then that would be a pretty solid contribution IMO.

In terms of actually writing bindings that are useful here's a proposal:

• Start off with a "dumb" wrapper. This is close to what you've been doing in your prototype: a 1-to-1 safe wrapper that is basically the minimum safe wrapper around the xed C api. This should be easy enough and docs can be lifted from the existing xed docs.
• Take that wrapper and shove it in a raw submodule
• Build proper, and easy-to-use high-level wrappers on top of the dumb wrapper.

This is no small amount of work :) - and all the extra to work to get it well documented will be a even more work. I do think it's worth doing though.

I'm going to assume that you want to do this. I'll go ahead and create the repo, reserve the crate name, and give you access to both next weekend. That way you have a chance to at least see this message before I do anything :)

[flier]

I think you've got it pretty much right on library positioning: we're making xed easier to use from within rust. The benefits we provide should be the same ones that xed does and I think your list there is accurate. If we can make our hypothetical xed crate easy enough to use (intuitive, well documented, etc.) then that would be a pretty solid contribution IMO.

In terms of actually writing bindings that are useful here's a proposal:

• Start off with a "dumb" wrapper. This is close to what you've been doing in your prototype: a 1-to-1 safe wrapper that is basically the minimum safe wrapper around the xed C api. This should be easy enough and docs can be lifted from the existing xed docs.
• Take that wrapper and shove it in a raw submodule
• Build proper, and easy-to-use high-level wrappers on top of the dumb wrapper.

This is no small amount of work :) - and all the extra to work to get it well documented will be a even more work. I do think it's worth doing though.

I'm going to assume that you want to do this. I'll go ahead and create the repo, reserve the crate name, and give you access to both next weekend. That way you have a chance to at least see this message before I do anything :)

Agree, I guess we need a raw module for the thin API wrapper, a enc and dec module for high level wrapper, maybe a seclang module for XED mini assembly language, and maybe a macros module for runtime instruction generating.

If we need enc2 based instruction generator, we may need a tools to parse XED data file to automatic generate wrapper, that's a huge set of API :)

[Phantomical]

I've gone ahead and created a repo over at https://github.com/rust-xed/xed and I have also sent you an invite to join the rust-xed org.

Since you said you weren't quite happy with your prototype I decided to give it a shot on my own and I think it turned out all right. I have most of the decode API wrapped - which turned out to be a rather large job - and an example on how to use it. I have translated the method documentation over but while xed is decently well documented for a C library there are still a bunch of types for which we will have to write our own documentation.

[flier]

I've gone ahead and created a repo over at https://github.com/rust-xed/xed and I have also sent you an invite to join the rust-xed org.

Since you said you weren't quite happy with your prototype I decided to give it a shot on my own and I think it turned out all right. I have most of the decode API wrapped - which turned out to be a rather large job - and an example on how to use it. I have translated the method documentation over but while xed is decently well documented for a C library there are still a bunch of types for which we will have to write our own documentation.

No problem, you first according to your ideas to construct it, I will add my ideas based on your codebase, or you have any task need help, submit issue to me!