rust-xed / xed-sys

Rust FFI bindings for Intel XED

xed-sys

Rust FFI bindings for Intel XED.

/// Similar to `examples/xed-min.c` from official Intel XED repository.
use xed_sys::*;

fn main() {
    unsafe {
        let (mmode, stack_addr_width) = (XED_MACHINE_MODE_LEGACY_32, XED_ADDRESS_WIDTH_32b);

        xed_tables_init();

        let itext: [u8; 15] = [
            0xf, 0x85, 0x99, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        ];

        for bytes in 0..16 {
            let mut xedd = ::std::mem::MaybeUninit::<xed_decoded_inst_t>::uninit();
            xed_decoded_inst_zero(xedd.as_mut_ptr());
            xed_decoded_inst_set_mode(xedd.as_mut_ptr(), mmode, stack_addr_width);

            let xed_error: xed_error_enum_t = xed_decode(xedd.as_mut_ptr(), itext.as_ptr(), bytes);
            let desc = std::ffi::CStr::from_ptr(xed_error_enum_t2str(xed_error)).to_string_lossy();
            println!("bytes={} error={}", bytes, desc);
        }
    }
}

Building

In order to build this crate, you need:

• Python version 3.8 or later (to build XED).
• A C compiler.

If you have the bindgen feature enabled then you will also need:

• clang to run bindgen.

Examples

You can find usage examples in the examples/ directory.

These examples are meant to be executed with cargo. For instance, to run the example named xed_min:

# cd to the crate's root directory
cargo run --example xed_min

xed-sys's Issues

Set up package metadata

See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata

Simpler binding

Hello all,

In the current build script, I find that sometimes we need copy the source folders (i.e. xed and mbuild), that may be not necessary.

Could you please take a look at this WIP branch which proposes a simpler build script.

Many thanks for any response.

[Discussion] Move all functions into the crate namespace?

Currently, we have two top-level modules: xed_interface and xed_version.

• xed_version contains xed_get_version and xed_get_copyright
• xed_interface contains everything. This includes xed_get_version and xed_get_copyright.

This is... not quite optimal. I propose that we simply export everything in the root module.

For backwards compatibility we need to keep the xed_interface and xed_version modules. However, they can be defined like this:

pub mod xed_interface {
    pub use crate::xed_interface_internal::*;
}
pub mod xed_version {
    pub use crate::{xed_get_version, xed_get_copyright};
}

where xed_interface_internal is wherever we actually import everything. This approach allows for the rustdoc to be nicer as well. Note that this approach ensures that we don't export xed_interface::xed_interface::etc which would be needlessly messy.

I wouldn't mark xed_interface and xed_version as deprecated just yet since that seems too quick to do in a single version bump. We can do that later whenever we feel like creating a 3.0 version.

Thoughts?

[Discussion] any plan to for high level binding?

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!

Discussion: how to deal with XED's static inline functions

Bindgen is currently unable to deal with functions declared as static inline (see #1344 and #1090).
XED has way too many functions like this.

The current workaround being used in this repository is to manually run c2rust to transpile the whole functions.

Disadvantages of current approach

1. Updating the XED git submodule to a newer version requires manually running c2rust.
2. (I'm not sure about this one) The transpiled code may be architecture-dependant in some way, since the function's code is generated for a fixed processor architecture and potentially run on a different architecture.

Possible solutions

1. Change build.rs so that c2rust is run in conjunction with bindgen.
2. Implement the feature we need in bindgen.

About crate ownership

The name xed-sys is already taken on crates.io, which is unfortunate.

I wonder if the owner @valarauca is interested in joining us to make a crates.io release with the name xed-sys. This way we would avoid creating unnecessary fragmentation in the Rust ecosystem.

If so, we'd have to:

• Change this crate's name on Cargo.toml from xed-sys2 to xed-sys.
• Change this crate's version to a number strictly greater than the current version on crates.io. I think it should be 0.2.0 since we'll introduce a breaking change in one way or another.

Change crate name/version

After merging #13:

• Change this crate's name on Cargo.toml from xed-sys2 to xed-sys. Update examples/xed-min/Cargo.toml.
• Change this crate's version to 0.2.0.

Set up crate documentation

See https://doc.rust-lang.org/cargo/reference/manifest.html#the-documentation-field-optional

We need just an overall description, users should refer to original XED docs for details.

New crates.io release

With the changes that have gone in recently it'd probably be good to do a crates.io release :)

While you're at it, it would be good to add either me or rust-xed as an owner on crates.io so that we don't have to go through this again.

xed-sys won't build with Python 3.9

See https://bugs.python.org/issue42189 and intelxed/mbuild#30

I'm working around this with https://github.com/rocallahan/xed-sys/commit/9b3b7a925f147fdfb1d7baa46cc5c7556249401a and https://github.com/rocallahan/mbuild/commit/b4580b926df935b04ceb62d3682e66584bdc72c9

Maybe Xed will land a workaround upstream, maybe Python will fix the regression, or maybe you want to work around it by forking/patching mbuild yourself.