Generation of overflow operations on estimating constant type sizes

[mj-unseld]

Hello,

in trying to implement some Rust in my ESP-32 C application, a was able to do it with cbindgen. Now I tryed it backward to use the C-libraries in Rust from my C-environment. It seems, that bindgen is not able to estimate the sizes of structs, or combined structs correctly and produces overflow operations.

Prelude: In doing so, I recognized that the Xtensa Clang version, respectively the libclang.dll version, is not supported by bindgen, so I switched to the standard one. So the result is not a native compiled solution but thought to give it a shot. I looked promising with my small example C-code. This could be one or the issue aspect.

Input gptimer.h

typedef struct {
    gptimer_alarm_cb_t on_alarm; /*!< Timer alarm callback */
} gptimer_event_callbacks_t;

Output bindings.rs

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct gptimer_event_callbacks_t
{
    #[doc = "< Timer alarm callback"]
    pub on_alarm: gptimer_alarm_cb_t,
}
#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
    ["Size of gptimer_event_callbacks_t"][::core::mem::size_of::<gptimer_event_callbacks_t>() - 8usize];
    ["Alignment of gptimer_event_callbacks_t"][::core::mem::align_of::<gptimer_event_callbacks_t>() - 8usize];
    ["Offset of field: gptimer_event_callbacks_t::on_alarm"]
        [::core::mem::offset_of!(gptimer_event_callbacks_t, on_alarm) - 0usize];
};

Bindgen Invocation

Using the following bindgen command line

$ bindgen ./wrapper.h -o /out/bindgen.rs + --ctypes-prefix=cty --use-core --I first-include-path -I second_include_path ... -I last-include-path

Actual Results

When compiling my Rust lib with using the C-FFI, following result appears.

error[E0080]: evaluation of constant value failed
    --> rs_src\out/bindings.rs:3634:43
     |
3634 |     ["Size of gptimer_event_callbacks_t"][::core::mem::size_of::<gptimer_event_callbacks_t>() - 8usize];
     |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `4_usize - 8_usize`, which would overflow

Expected Results

#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
    ["Size of gptimer_event_callbacks_t"][::core::mem::size_of::<gptimer_event_callbacks_t>() - 4usize];
    ["Alignment of gptimer_event_callbacks_t"][::core::mem::align_of::<gptimer_event_callbacks_t>() - 4usize];
    ["Offset of field: gptimer_event_callbacks_t::on_alarm"]
        [::core::mem::offset_of!(gptimer_event_callbacks_t, on_alarm) - 0usize];
};

[emilio]

The overflow is letting you know that the pointer sizes etc don't match. You need to pass the right target information to clang (and to bindgen).

[mj-unseld]

So, this brings me to my initial problem of using the libclang.dll provided by espressif/xtensa for the esp-32 platform. Clang seems not to be able to open the provided dll, why I had to change the LIBCLANG_PATH env variable. Is it possible on any way to use bindgen with clang and passing the necessary libclang fork? Otherwise I'd have to look for a similiar architecture/target compared to the esp-32 platform which is supported by the clang version and hoping for the best.

Amendment: I assigned the riscv-unknown-gnu as target to clang and added the include path of stdio.h from the esp-platform and let it compile. Suprisingly it worked and gets adopted by the rust and c compiler with just printing not-ffi-safe, upper-case-globals and camel-case-naming warnings.

Open: It would satisfy my inner peace, if clang and bindgen would use the libclang.dll provided by xtensa/espressif for the ESP-platform, thus the compilation result makes fully use of the platform and is fully supported. The current solution is just a workaround with lots of unclearence how well it is adopted by the target platform. It is still unclear to me, why the libclang.dll don't get adopted by bindgen and clang.

Wish: Introduce support for the libclang.dll fork provided by espressif/xtensa.
Question: From where does this issue (file not found) arise, when the espressif/xtensa fork of libclang.dll is passed as LIBCLANG_PATH to clang/bindgen?

[pvdrz]

if you want to use a specific libclang you should set LIBCLANG_PATH. If you want to use a specific clang executable you should set CLANG_PATH.