Compiler built-ins from a Rust static lib being used by the C-based caller

Embedded
1

I'm in the process of linking a Rust static lib to the nRF52 based embedded environment and having a moderate amount of success. However, I'm now experiencing something quite foreign to me. It appears as though compiler built-ins from my Rust world are being called in relation to a non-Rust C function (ble_device_addr_encode).

Any pointers on how I may avoid this? It doesn't feel right that the Rust built-ins are being called here.

One thing I've tried is the following config for my static lib, but with no success, presumably because my static lib project doesn't invoke the linker; my C project does:

[target.thumbv7em-none-eabihf]
rustflags = [
    "-C", "linker=arm-none-eabi-ld",
    "-C", "link-arg=-Wl,-Tlink.x",
    "-C", "link-arg=-nostartfiles",
]

Here's the backtrace from GDB.

Program received signal SIGTRAP, Trace/breakpoint trap.
HardFault_Handler () at /opt/nordic/nRF5_SDK_17.0.2_d674dde/modules/nrfx/mdk/gcc_startup_nrf52840.S:302
302	    b       .
(gdb) back
#0  HardFault_Handler () at /opt/nordic/nRF5_SDK_17.0.2_d674dde/modules/nrfx/mdk/gcc_startup_nrf52840.S:302
#1  <signal handler called>
#2  core::str::validations::unwrap_or_0 () at library/core/src/str/validations.rs:30
#3  core::str::validations::next_code_point () at library/core/src/str/validations.rs:62
#4  <core::str::iter::Chars as core::iter::traits::iterator::Iterator>::next () at library/core/src/str/iter.rs:41
#5  <core::str::iter::CharIndices as core::iter::traits::iterator::Iterator>::next () at library/core/src/str/iter.rs:145
#6  core::iter::traits::iterator::Iterator::nth () at library/core/src/iter/traits/iterator.rs:368
#7  core::fmt::Formatter::pad () at library/core/src/fmt/mod.rs:1317
#8  0x0003c086 in compiler_builtins::mem::memcmp () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/mem.rs:56
#9  compiler_builtins::mem::bcmp () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/mem.rs:68
#10 0x0003309c in ble_device_addr_encode (p_encoded_data=0x28fcd <app_sched_execute+72> "K\033x۲\030F\377\367\322\376\003F\032F\tK\032p\377\367\310\377\003F\203\360\001\003۲", p_offset=0x2003ffd8, max_size=8192)
    at /opt/nordic/nRF5_SDK_17.0.2_d674dde/components/ble/common/ble_advdata.c:77
#11 0x00033168 in name_encode (p_advdata=0x2728f <_start+78>, p_encoded_data=0x0, p_offset=0x0, max_size=0) at /opt/nordic/nRF5_SDK_17.0.2_d674dde/components/ble/common/ble_advdata.c:117
#12 0x00000000 in ?? ()

Thanks for any help.

2

This could also be a situation where I may have corrupted the stack. :slight_smile: Investigating further.

3

Looks as though I jumped into some code given a unsafe C param passing of a value that was then used in a match statement... Resolving this.

4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.