Undefined reference when using atomics (LLVM-58)

[lexxvir]

Hi,

I encountered into issue when try to use Rust compiler's AtomicBool.

Linker error: undefined reference to __sync_lock_test_and_set_1.
Quite same error for AtomicUsize: undefined reference to __sync_lock_test_and_set_4.

It seems that LLVM somehow should replace these symbols by real atomic instructions for xtensa target.

[pacmancoder]

Does anyone found workarounds for Atomics support in Rust for the current LLVM state?

[lexxvir]

Personally I replaced all Atomics by FreeRTOS Mutexes, though I have only few Atomics in whole codebase.

[pacmancoder]

I can imagine that it is possible to write a bit of shim code in C with it's bultins and then link this library with rust application, but I am not tried this yet.

Yes, we can use free rtos sync primitives, but anscense of rust atomics is blocking use of the Arc from alloc crate, which is a bit sad. :(

[pacmancoder]

@lexxvir Looks like my idea is working. I made shim c-code to call gcc builtins and exported these functions in the rust code. With this shim layer, code using atomics can be compiled.

Here is my gist:
https://gist.github.com/pacmancoder/70788fc112b582f71f885e2c3104c0ab

I made .c and .rs files generation script in python (btw, sorry for the very dirty code).

I am not performed a lot of testing yet, but I will try integrate this worarround in my current work in idf-hal/idf-sys projects (yep, shameless plug) and will tell if it works correct.

UPD: Performed generation script refactoring. Now it looks more adequate 🛩️

[lexxvir]

@pacmancoder I have not experience in such low level code, so I'm probably not right, but is such shims must be marked as "inline always" both in C and in Rust? Or inlining will be done by compiler auto-magically?

BTW, just FYI, there are wrapper crates for ESP IDF made by @sapir: esp-idf-sys, esp-idf-hal.

[pacmancoder]

@lexxvir specifying code inlining for this case is quite problematic, as C-shims should be represented as valid functions to be able to link them from the rust side. I think this inlining can be handled automatically by the compiler on the link stage when -flto (link time optimizations) is specified. (related thread).

Anyway, it is just a quick and dirty worarround, and I hope the issue with atomics will be fixed in LLVM-Xtensa

About the projects by @sapir: I know about them, he did a great work 👍 ! But I decided to write my own version of the crates with more configurability (to not bound user to the specific sdkconfig and even platform (I plan to support both esp8266 and esp32) and with less unsafe code (owned periperals singletone and direct ownership of the separate peripherals). Because of lack of the time, its development is going very slow (For now, I implemented only wifi ap/sta configuration) but I hope I will make it usable in a few months

[vgarleanu]

pinging @lexxvir and @pacmancoder . Whats the status on this? I am still getting this linking error when using rustc

[lexxvir]

Hi @vgarleanu !

I just tested it again, on recent compiler (see #20) and it's OK. Code links successfully and runs without issue. I my test I just incrementing AtomicUsize in the loop by the two threads and output the values.

[vgarleanu]

@lexxvir Thanks a lot for taking your time to test it out on your system. I just did some more testing myself and it seems that only AtomicBool causes a linker error throwing undefined reference to __sync_lock_test_and_set_1'. AtomicUsize works fine.
UPDATE: It actually turns out that the linker error is caused when the swap method of any Atomic is used.
Do you mind testing it on your side? FYI my snippet is just this:

#[no_mangle]
pub fn app_main() {
    static FIRST_PANIC: AtomicBool = AtomicBool::new(true);
    FIRST_PANIC.swap(false, SeqCst);
}

P.S. I am also using the latest commit of https://github.com/MabezDev/rust-xtensa. I just placed that snippet inside the main.rs of https://github.com/lexxvir/esp32-hello

[lexxvir]

@vgarleanu Yeah, you're right, swap leads to the linker error for me too:
__sync_lock_test_and_set_1 for AtomicBool and __sync_lock_test_and_set_4 for AtomicUsize.

Just in case, my test:
atomic.zip

[vgarleanu]

@lexxvir Alright, how do we go about tracking the cause down? Is there any maintainer from espressif that we can ping in?

[lexxvir]

@vgarleanu I think @andreisfr or @igrr could help here...

[vgarleanu]

Should i perhaps open a separate issue? Im unsure if this bug relates with the one atop.

[reitermarkus]

@vgarleanu, I think we are all talking about the same bug. I can confirm this bug still exists in the newest version. I am still using the C shim @pacmancoder mentioned as a workaround for now.

[andreisfr]

@lexxvir , @vgarleanu , thank you for information, we investigate the problem.

[vgarleanu]

hey @andreisfr whats the status on this?

[lexxvir]

Hi there,

I've just built new Rust compiler using xtensa_release_11.0.0 branch and it seems compiler now has atomics!
To check that I've used test from #3 (comment).

[vgarleanu]

Gotcha, ill check everything on my side sometime this week!

[gerekon]

Closed as it was fixed by https://github.com/espressif/llvm-project/tree/xtensa_release_11.0.0