Created attachment 305126 [details] sample rust package build log Since this commit: commit 8ee0b41898fa26f66e32237f179b6989c65600d6 Author: Greentime Hu <greentime.hu@sifive.com> Date: Mon Jun 5 11:07:11 2023 +0000 riscv: signal: Add sigcontext save/restore for vector running rustc on riscv produces output like this: $ rustc test.rs /usr/lib/rust/lib/librustc_driver-f0248bec779deb29.so(+0xe8ebdc)[0x3f8dc8ebdc] linux-vdso.so.1(__vdso_rt_sigreturn+0x0)[0x3f8fb91800] /lib64/libc.so.6(syscall+0x16)[0x3f8cbfacbe] /usr/lib/rust/lib/libstd-985e4b663b8154c3.so(_ZN3std3sys4unix5locks13futex_condvar7Condvar4wait17h4e3b669d2690824dE+0x64)[0x3f8cd45f68] /usr/lib/rust/lib/librustc_driver-f0248bec779deb29.so(+0x715ab6)[0x3f8d515ab6] /usr/lib/rust/lib/librustc_driver-f0248bec779deb29.so(+0x7159ce)[0x3f8d5159ce] /usr/lib/rust/lib/librustc_driver-f0248bec779deb29.so(+0x6b64f6)[0x3f8d4b64f6] /usr/lib/rust/lib/librustc_driver-f0248bec779deb29.so(+0x715534)[0x3f8d515534] /usr/lib/rust/lib/libstd-985e4b663b8154c3.so(rust_metadata_std_9e9c65f710e3ce43+0xaba32)[0x3f8cd44a32] /lib64/libc.so.6(+0x6a8e4)[0x3f8cbab8e4] /lib64/libc.so.6(+0xbb49c)[0x3f8cbfc49c] even for a simple hello world program. The output being present does not necessarily mean that the compilation failed, in fact often it will still return 0 and produce a working binary despite the output, but often it does not, frequently enough that it's impossible to build large rust packages. See the attached log for an example of a real build which fails partway through (despite the fact that all compilation lines emit the traceback).
(In reply to matoro from comment #0) > Created attachment 305126 [details] > sample rust package build log > > Since this commit: > > commit 8ee0b41898fa26f66e32237f179b6989c65600d6 > Author: Greentime Hu <greentime.hu@sifive.com> > Date: Mon Jun 5 11:07:11 2023 +0000 > > riscv: signal: Add sigcontext save/restore for vector > > running rustc on riscv produces output like this: > > $ rustc test.rs > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > so(+0xe8ebdc)[0x3f8dc8ebdc] > linux-vdso.so.1(__vdso_rt_sigreturn+0x0)[0x3f8fb91800] > /lib64/libc.so.6(syscall+0x16)[0x3f8cbfacbe] > /usr/lib/rust/lib/libstd-985e4b663b8154c3. > so(_ZN3std3sys4unix5locks13futex_condvar7Condvar4wait17h4e3b669d2690824dE+0x6 > 4)[0x3f8cd45f68] > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > so(+0x715ab6)[0x3f8d515ab6] > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > so(+0x7159ce)[0x3f8d5159ce] > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > so(+0x6b64f6)[0x3f8d4b64f6] > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > so(+0x715534)[0x3f8d515534] > /usr/lib/rust/lib/libstd-985e4b663b8154c3. > so(rust_metadata_std_9e9c65f710e3ce43+0xaba32)[0x3f8cd44a32] > /lib64/libc.so.6(+0x6a8e4)[0x3f8cbab8e4] > /lib64/libc.so.6(+0xbb49c)[0x3f8cbfc49c] > > even for a simple hello world program. The output being present does not > necessarily mean that the compilation failed, in fact often it will still > return 0 and produce a working binary despite the output, but often it does > not, frequently enough that it's impossible to build large rust packages. > See the attached log for an example of a real build which fails partway > through (despite the fact that all compilation lines emit the traceback). What's your test.rs snippet?
(In reply to Bagas Sanjaya from comment #1) > (In reply to matoro from comment #0) > > Created attachment 305126 [details] > > sample rust package build log > > > > Since this commit: > > > > commit 8ee0b41898fa26f66e32237f179b6989c65600d6 > > Author: Greentime Hu <greentime.hu@sifive.com> > > Date: Mon Jun 5 11:07:11 2023 +0000 > > > > riscv: signal: Add sigcontext save/restore for vector > > > > running rustc on riscv produces output like this: > > > > $ rustc test.rs > > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > > so(+0xe8ebdc)[0x3f8dc8ebdc] > > linux-vdso.so.1(__vdso_rt_sigreturn+0x0)[0x3f8fb91800] > > /lib64/libc.so.6(syscall+0x16)[0x3f8cbfacbe] > > /usr/lib/rust/lib/libstd-985e4b663b8154c3. > > > so(_ZN3std3sys4unix5locks13futex_condvar7Condvar4wait17h4e3b669d2690824dE+0x6 > > 4)[0x3f8cd45f68] > > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > > so(+0x715ab6)[0x3f8d515ab6] > > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > > so(+0x7159ce)[0x3f8d5159ce] > > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > > so(+0x6b64f6)[0x3f8d4b64f6] > > /usr/lib/rust/lib/librustc_driver-f0248bec779deb29. > > so(+0x715534)[0x3f8d515534] > > /usr/lib/rust/lib/libstd-985e4b663b8154c3. > > so(rust_metadata_std_9e9c65f710e3ce43+0xaba32)[0x3f8cd44a32] > > /lib64/libc.so.6(+0x6a8e4)[0x3f8cbab8e4] > > /lib64/libc.so.6(+0xbb49c)[0x3f8cbfc49c] > > > > even for a simple hello world program. The output being present does not > > necessarily mean that the compilation failed, in fact often it will still > > return 0 and produce a working binary despite the output, but often it does > > not, frequently enough that it's impossible to build large rust packages. > > See the attached log for an example of a real build which fails partway > > through (despite the fact that all compilation lines emit the traceback). > > What's your test.rs snippet? Hello world copied from the documentation. $ cat test.rs // This is a comment, and is ignored by the compiler. // You can test this code by clicking the "Run" button over there -> // or if you prefer to use your keyboard, you can use the "Ctrl + Enter" // shortcut. // This code is editable, feel free to hack it! // You can always return to the original code by clicking the "Reset" button -> // This is the main function. fn main() { // Statements here are executed when the compiled binary is called. // Print text to the console. println!("Hello World!"); }
Note also that I tested both with the official upstream distributed rustc binaries, and with one compiled from source against system llvm (16.0.6). I also tried all rust versions in between 1.70.0 and 1.72.0 inclusive. Issue was present for all rustc versions tried.
A comment from the cheap seat gallery (this is not my area of expertise): there was a fix for the culprit that once was applied, but is not in mainline yet; I wonder if it might be related somehow: https://lore.kernel.org/all/20230822164904.21660-1-andy.chiu@sifive.com/
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #4) > A comment from the cheap seat gallery (this is not my area of expertise): > there was a fix for the culprit that once was applied, but is not in > mainline yet; I wonder if it might be related somehow: > > https://lore.kernel.org/all/20230822164904.21660-1-andy.chiu@sifive.com/ Thanks Thorsten, tested and confirmed this patch indeed fixes the issue. If and when this gets submitted to mainline, could it please also be backported to stable?