Meeting 2025-10-14

[thejpster]

This is the agenda for the next meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• IRC/Matrix logs

[thejpster]

Idea - should we create a separate Matrix room just for WG members, just for WG stuff, like discussing PRs we've received, or new members? Just to keep it separate from the general Rust Embedded chat.

[BartMassey]

I think a WG meeting room would be good. I would prefer to keep it publicly accessible: anything we want to discuss privately should probably be on a private chat. I can't keep up with the R-E Matrix room as it is, so seeing the stuff that matters to REWG would be helpful to me.

[ejpcmac]

As a non-WG member, I find it valuable to be able to read the discussion logs: I can keep up with the current subjects and questions around core Embedded Rust topics. So, +1 for a separate public room.

[adamgreig]

Set up https://matrix.to/#/#rust-embedded-wg:matrix.org for this purpose. It's world accessible but we can use it to discuss WG-specific items. We'll keep the meetings in the main channel.

[BartMassey]

We should discuss this new PR I think rust-embedded/embedonomicon#101. It seems to me to be important.

Personal opinion: We should figure out what we want to ask/check with the Language Team for as far as the ability to do things like this in Rust. In my opinion, Rust > ASM for this kind of stuff, but only if we can get some officially blessed way to make sure it all will continue to work. Failing that, we should accept this PR.

[adamgreig]

We chatted about this and concluded we should accept the PR as is; it's not likely that Rust will be able to do initialisation in the foreseeable future for the reasons discussed in the PR.

[jonathanpallant]

armv8r-none-eabihf and armv7r-none-eabihf are now Tier 2, and have been added to CI. Both should be available in nightly in a few days, if I got the CI setup right. The armebv7r-none-eabi* targets are also removed from rustup because they are now Tier 3.

[thejpster]

GCC compatibility

I observed recently that it’s non-obvious what flags you should pass to gcc to generate object code that is compatible with (and/or equivalent to) that produced by a given rust target.

For example: is armv7r-none-eabihf going to assume double precision FPU, or only single precision? Is -march=armv7-r enough? (Spoilers - it is not).

This information is useful to cc-rs in particular, who seem to be doing things ad-hoc. Also, I think compiler-builtins needs to know this?

How do we feel about adding that information to each of the target pages for the targets we maintain? It’s a bit odd documenting flags for another compiler, but I don’t think gcc is going to note the compatibility on their side and I don’t know where else it would go. I guess you could argue the cc-rs source is canonical but that’s not very discoverable. Another option is the target spec itself, but … ugh.

[diondokter]

I think this is gonna be a broader question in Rust too with rust in gcc and the gcc backend in rust. So maybe rust project members have ideas about this too

[d3zd3z]

This gets non-trivial rather quickly, too. I've captured some of this for Zephyr in https://github.com/zephyrproject-rtos/zephyr-lang-rust/blob/161825c50a7870017e52afc29169816c7f4500b4/CMakeLists.txt#L14, and there is a pending patch to improve the RISC-V version. Although, this mapping is in the other direction.