Stuff that needs to be upstreamed / fixed in libc and Rust STD

[ivmarkov]

(work in progress)

[ivmarkov]

This PR needs to be brought to completion (for target_os = "espidf" at least)

The author was kind enough to provide a script that (as far as I recall) compares the sizes and values of various structs and constants hard-coded in the libc crate against the "real thing" (headers for the relevant platform).

So what's necessary here is to first of all adjust the script so that it uses the ESP IDF toolchain, and the ESP IDF headers. Then once it spits out its analysis, we need to fix all structs and constants reported as wrong in the libc crate (for ESP IDF only, of course)

[SergioGasquez]

Just opened rust-lang/libc#3920 which should solve this

[ivmarkov]

This is now resolved, thanks to @SergioGasquez

[ivmarkov]

(Might be fixed by the previous PR but needs to be researched anyway)

IPv4 multicast is currently broken for the ESP IDF in Rust STD.
Here's a relevant workaround, which uses structs and constants defined by esp-idf-sys rather than the ones in libc and thus works

[SergioGasquez]

I suppose this should be also fixed once rust-lang/libc#3920 is merged

[ivmarkov]

This is now also resolved.

[ivmarkov]

Flip (or completely remove) the espidf_time64 flag

• If we decide to completely remove it - like now - we have to immediately announce we are effectively killing any support for ESP IDF 4.4.x (reason: every ESP IDF version uses its own toolchain; the toolchain downloaded when ESP IDF 4.4.x is used has the timeval thing still set to 32 bit). And we'll of cpourse default to 64bit, which is compatible with ESP IDF >= 5

• If we decide to keep it, here's my suggestion (open for comments):

  • introduce a new flag: espidf_time32
  • keep the existing flag too: espidf_time64

Resolve timeval to 32 (= ESP-IDF 4) or 64 (= ESP-IDF 5) bits as follows:

-----------------------------------------------------------
| timeval     | espidf_time64  | espidf_time32  
|--------------------------------------------------------- 
| = 64 bits   | Defined        | Not defined     
| = 32 bits   | Not defined    | Defined           
| = 64 bits   | Not defined    | Not defined     
| Comp Err    | Defined        | Defined            
------------------------------------------------------------

[SergioGasquez]

In case you missed it, rust-lang/libc#3175 seems to be progressing in the latest weeks. That being said, I like @Vollbrecht proposal.

[ivmarkov]

In case you missed it, rust-lang/libc#3175 seems to be progressing in the latest weeks. That being said, I like @Vollbrecht proposal.

This issue is about GNU libc. How is that relevant to our case (ESP IDF is based on newlib)?

[SergioGasquez]

This should be resolved when rust-lang/libc#3993 is merged

[SergioGasquez]

rust-lang/libc#3993 got merged! Now we should wait for a libc release and that release to be used in rust-lang/rust

[SergioGasquez]

This should now be resolved!

[ivmarkov]

(Finally) fix the (non-working) setting of stack size via std::thread::Builder

This is not working since forever, but I'm kind of tired telling the users that it does not work and they have to use the other workaround, so why not fixing it?

Not a high priority though.

[ivmarkov]

Watch out the development here

I think we have posix_memalign in ESP IDF >= 4.4, but still good to double-check, or else that would break everything for us.

[SergioGasquez]

Is there any action items on our side now that the mentioned PR has been merged?

[ivmarkov]

No this is no longer an issue. Topic closed.

[ivmarkov]

Talk to the LLVM Espressif team about the async-io issue

... and if necessary, create a small(er) test case etc.

Note: While not strictly a Rust STD / libc work, in a way async-io is the way to do async IO with Rust STD for ESP-IDF.

[ivmarkov]

After all of the above is done - lobby for moving the riscv -espidf targets to Tier 2

... because the only unstable feature we use from Rust is actually in cargo, and it is -Zbuild-std...

So Tier 2 would give us Stable Rust for STD!

[Vollbrecht]

The build-std is beeing looked into currently with the new forming of the wg-embedded group on rust,

[ivmarkov]

Great, but still might take years until stabilized. And I fear they might stabilize only the "build-core" aspect of build-std initially, which is of no use to us.

Do you have a link btw?

[Vollbrecht]

There are no actionable items yet, they were discussed at the RustNL unconference between members of the embedded group and some people of rust-lang. Here is the link to what was all discussed

[ivmarkov]

Yeah. Still no owner and as expected, people mainly want core, not the full circus. I think we should push for Tier 2 in parallel.

Unrelated: on that mtg there were complaints about async code size, but not about futures memory consumption? Weird!

[SergioGasquez]

We already started working on creating the MCP for this, we will be submitting it soon