@@ -18,6 +18,14 @@ RUST_DEBUG_REMAP = "--remap-path-prefix=${WORKDIR}=${TARGET_DBGSRC_DIR} \
--remap-path-prefix=${TMPDIR}/work-shared=${TARGET_DBGSRC_DIR} \
"
RUSTFLAGS += "${RUSTLIB} ${RUST_DEBUG_REMAP}"
+
+# musl on riscv32 only has 64-bit time_t, but the libc crate before 0.2.190
+# only uses the matching struct layouts (e.g. struct stat) when asked to, and
+# otherwise corrupts memory. 0.2.174 to 0.2.188 read the environment variable,
+# and 0.2.189 reads the cfg.
+RUST_LIBC_UNSTABLE_MUSL_V1_2_3:riscv32:libc-musl = "1"
+export RUST_LIBC_UNSTABLE_MUSL_V1_2_3
+RUSTFLAGS:append:riscv32:libc-musl = " --cfg libc_unstable_musl_v1_2_3"
RUSTLIB_DEP ??= "libstd-rs"
RUST_PANIC_STRATEGY ??= "unwind"
# See https://bugzilla.yoctoproject.org/show_bug.cgi?id=15976
musl on riscv32 only has a 64-bit time_t. The libc crate before 0.2.190 still uses 32-bit time_t struct layouts for riscv32 musl unless asked otherwise, so e.g. std's stat() passes a struct stat that is about 24 bytes smaller than the 128 bytes musl writes. This corrupts the stack, and any Rust program calling std::thread::available_parallelism() or std::fs::metadata() crashes: qemu: uncaught target signal 11 (Segmentation fault) - core dumped This affects std, which uses the vendored libc 0.2.189 in Rust 1.99.0, as well as crates using older libc versions. Upstream fixed it in libc 0.2.190 by always using the musl 1.2 layouts on riscv32 [1]. Until then, opt into them for riscv32 musl targets: libc 0.2.174 to 0.2.188 read the RUST_LIBC_UNSTABLE_MUSL_V1_2_3 environment variable, 0.2.189 the libc_unstable_musl_v1_2_3 cfg. Older versions have no musl time64 support. [1] https://github.com/rust-lang/libc/pull/5508 Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com> --- meta/classes-recipe/rust-common.bbclass | 8 ++++++++ 1 file changed, 8 insertions(+)