#intel #vtune #seapi #ittnotify #itt

sys intel-seapi-sys

FFI wrapper for Intel Single Event API (SEAPI) and ittnotify, as used by Intel VTune

3 unstable releases

Uses old Rust 2015

0.2.0 Oct 26, 2018
0.1.1 Oct 26, 2018
0.1.0 Oct 26, 2018

#4 in #vtune

40 downloads per month
Used in intel-seapi

MIT license

2MB
15K SLoC

Python 8K SLoC // 0.1% comments C++ 4K SLoC // 0.1% comments C 1.5K SLoC // 0.1% comments C# 1K SLoC FORTRAN Modern 409 SLoC // 0.1% comments Rust 319 SLoC // 0.0% comments Java 158 SLoC // 0.1% comments Objective-C++ 41 SLoC // 0.3% comments Visual Studio Solution 39 SLoC Batch 7 SLoC Shell 2 SLoC

intel-seapi

intel-seapi is a FFI wrapper for the Intel Single Event API (SEAPI, also known as IntelSEAPI) and ittnotify, as used by Intel VTune. ITT stands for 'Instrumentation and Tracing Technology'. This particular wrapper uses a fork of IntelSEAPI because the upstream code base doesn't support cross-compilation or the MUSL C library.

It provides a static link and generates Rust FFI bindings to the libittnotify.a/.obj library, and also compiles , but does not link or generate Rust bindings for, thelibIntelSEAPI.dylib/.so/.dll dynamic library (this is because it is only ever built dynamically and because it is designed to be used from C++).

Downstream crates can use the generated build variables cargo:include, cargo:libdir and cargo:root.

Limitations

  • Does not currently work on Windows, as a completely different set of APIs (ending in A and W) are built for Windows by libittnotify.
  • The dynamic library IntelSEAPI is built but not linked and no bindings are generated for it.
  • Bindgen does not generate correct bindings for most of libittnotify because the C headers' function declarations do not reflect the actual managled names created. Consequently only a small subset of bindings is provided; additional bindings generated but not yet corrected are in BindingsAsGeneratedByBingen.rs.

Cross-Compilation

This is brittle, and may fail, mostly because the underlying software uses a mixture of CMake, a C++ toolchain with Rust bindings and wrappers, and IntelSEAPI is not cross-compile friendly. We use a forked version to fix some cross-compilation mistakes in their CMakeLists.txt files, generation of fat Mac OS X object archives with architectures independent of target or host, etc.

For example, when compiling for MUSL targets, Rust's cc crate assumes the C compiler is musl-gcc and the C++ compiler if musl-g++. Since the cc crate is managed by the cmake crate, this is something we can't easy change. This crate attempts to set the environment variable CROSS_COMPILE if not set already when cross-compiling using a MUSL target.

Known cross-compilations that work.

  • On Mac OS X, with filo-sottie's foked musl homebrew keg installed (lemonrock/musl-cross/musl-cross), cargo build --target x86_64-unknown-linux-musl.

Licensing

The license for this project is MIT.

Dependencies