Outstanding patches for Rust STD support in ESP-IDF master & V4.3 branch (IDFGH-5970)

[ivmarkov]

@igrr asked me for a summary of what needs to be merged so that we have Rust STD support without patching the ESP-IDF SDK.

Here it goes:

Master

The only remaining ones are:

• Missing __atomic_load & __atomic_store intrinsics' implementation for esp32c3 (& maybe esp32s2) (IDFGH-5896) #7591 (affects esp32c3)
• Missing __sync_lock_test_and_set_ intrinsic for esp32s2 (IDFGH-5897) #7592 (affects esp32s2)
• Patch (for both) here.

V4.3

• Atomic issues:

  • Atomics for esp32c3 are not implemented at all in this branch, and have to be back-ported from master. I maintain a hacky backport in pure Rust here.
  • The atomics for esp32s2 suffer the same issue as Missing __sync_lock_test_and_set_ intrinsic for esp32s2 (IDFGH-5897) #7592 and need the same fix. Patch for V4.3 here

• Pthread local storage destructor semantics issue:

  • Fixed in master: (Suggested fix) pthread_local_storage_thread_deleted_callback is not conforming to the specification of pthread_key_create (IDFGH-4842) #6643 , needs backporting
  • Patch for V4.3 here (or better yet, cherry-pick from master)

• (Low prio, does not affect Rust actually) Pinging specific interface does not work:

  • Fixed in master: Pinging specific iface does not work: Fix broken parentheses in setsockopt call (IDFGH-5676) #7397
  • Patch for V4.3 here (or better yet, cherry-pick from master)

[ivmarkov]

Oh, and we need a pthread rwlock implementation (can't find the relevant issue in GitHub), but I guess that one should be tracked separately.

[0xjakob]

Oh, and we need a pthread rwlock implementation (can't find the relevant issue in GitHub), but I guess that one should be tracked separately.

#7411

[0xjakob]

@ivmarkov We currently have a PoC for rwlock using a condition variable. We haven't done any performance tests (runtime and mem usage) yet but so far it works in unit tests. Given that it's faster than a normal mutex, we could release this as a preliminary implementation until we have a better solution.

[ivmarkov]

Thanks for the link. Even if it is not faster than a normal mutex, we might still want to use it in Rust STD as-is.