Closed s117 closed 4 years ago
In short, it happens because of an OS API difference. It has been thoroughly discussed in these two related issues: https://github.com/riscv/riscv-gnu-toolchain/issues/510 https://github.com/riscv/riscv-tools/issues/229
One workaround is to use the Linux encoding overriding the newlib's FreeBSD-style encoding, as provided by https://github.com/s117/riscv-newlib/commit/90283440c35651d12622fd2e4135308ed107cec8
Though seems dirty, it does work.
➜ fwrite_test ls
fwrite.c
➜ fwrite_test riscv64-unknown-elf-gcc -g fwrite.c -o fwrite
➜ fwrite_test ls
fwrite fwrite.c
➜ fwrite_test spike pk fwrite
Requesting target memory 0x100000000
******* Resetting core **********
****Initializing the processor system****
******* Resetting core **********
******* Resetting core **********
****Initialization complete****
O_CREAT=0x00000040
Temporary file ./bombesin.hmm.new was opened correctly.
******* Resetting core **********
➜ fwrite_test ls
bombesin.hmm.new fwrite fwrite.c
➜ fwrite_test cat bombesin.hmm.new
TEMPDATA
58d5ac3 updated submodule riscv-gnu-toolchian to incorporate this patch
We expect that the libc call
fopen("XYZ", "w")
creates an empty file named "XYZ" for output operations. But with 9.2.0 newlib toolchain aforementioned call returns NULL.This weird behavior is observed when running SPEC2006 456.hmmer_ref.
A C code piece to reproduce this problem:
Result: