Error when compiling Timer.lf program under FlexPRET

[ChadliaJerad]

After successfully installing the RISC-V GNU toolchain and Verilator (version 5.002), running lfc scr/Timer.lf outputs the following error at the end:

**** To get simulation outputs:
cd /home/chadlia/berkeleyWorkspace/lf-flexpret/src-gen/Timer; fp-emu +ispm=Timer.mem

riscv32-unknown-elf-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory
compilation terminated.
make: *** [Makefile:47: Timer.riscv] Error 1
Compiled binary is in /home/chadlia/berkeleyWorkspace/lf-flexpret/bin
Code generation finished.

The nosys.specs is located under /home/chadlia/berkeleyWorkspace/riscv-gnu-toolchain/newlib/libgloss/libnosys/nosys.specs though.

Also, when running fp-emu +ispm=Timer.mem, I get this message: %Warning: Timer.mem:0: $readmem file not found and then nothing is running, despite it is said that it is a warning.

Any pointers, please?

[lsk567]

Thanks for reporting the issue, @ChadliaJerad.

It looks like the main issue is:

riscv32-unknown-elf-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory
compilation terminated.

Because the compilation was unsuccessful, Timer.mem was not generated, hence the error $readmem file not found.

What is the version of your RISC-V GNU toolchain, and did you follow these instructions when installing it?

[ChadliaJerad]

Thanks, Shaokai!
I have the 12.2.0 version of riscv32-unknown-elf-cpp installed.

[lsk567]

Yes, 12.2.0 is the same version I have.

It could be that the spec files, for some reason, are not in your installation path. /home/chadlia/berkeleyWorkspace/riscv-gnu-toolchain/newlib/libgloss/libnosys/nosys.specs seems to be in the repository and not in the installation itself.

My installation path is /opt/riscv, and the nosys spec files are under /opt/riscv/riscv32-unknown-elf/lib. Can you check if these spec files are in your installation path too?

[ChadliaJerad]

I set the installation path ~/berkeleyWorkspace/riscv/ instead of /opt/riscv. Surprisingly, there is only these folders in it: bin include lib libexec riscv64-unknown-elf share
Not even riscv32-unknown-elf.
Actually, I started the default installation, which is risc64, but stopped and moved to the riscv32.
I will clean everything up, re-install, and let you know.

[ChadliaJerad]

Update: it turned out that the riscv64 is the one that was built.
After cleaning, the following configuration cmd ./configure --prefix=/opt/riscv --with-arch=rv32i --with-abi=ilp32 from https://github.com/pretis/flexpret#risc-v-compiler failed when calling make.
However, the configuration cmd ./configure --prefix=/opt/riscv --with-arch=rv32gc --with-abi=ilp32d from https://github.com/riscv-collab/riscv-gnu-toolchain#prerequisites does not fail calling make. But it still running since a couple of hours...

[lsk567]

After cleaning, the following configuration cmd ./configure --prefix=/opt/riscv --with-arch=rv32i --with-abi=ilp32 from https://github.com/pretis/flexpret#risc-v-compiler failed when calling make.

Could you show the error message you got when calling make?

[ChadliaJerad]

I am sorry I cannot! Currently experimenting with another configuration of the compiler...

Still, it occurred to me that I should rather do make linux, since I am on Ubuntu. Thanks to the lab shared by Martin, riscv64-unknown-elf-[something] is for macOS, while riscv64-linux-elf-[something] is for Linux.

Another thing I understood from your post regarding submodules on Zilup, I was using the lfc compiler built locally from one of the branches of the lf-lang repo on github. But even on master, it did not work.

[lsk567]

Since the riscv gcc is a cross-compiler, I think it's the target environment, rather than the host environment, that determines which gcc should be used. Since we are targeting an embedded environment (FlexPRET) instead of a riscv-based linux distribution, we probably want to use the riscv64-unknown-elf-[something] instead of riscv64-linux-elf-[something]...

[ChadliaJerad]

Please have a look at the description here, regarding the naming... This is what I meant.

Now that make succeeded (I don't know why it worked now after a number of trials) and that lfc is built from the version pointed out by this repo, I was able to emulate Timer.lf.

As mentioned in Zulip, and possibly for Linux users, using prebuilt binaries could be an easier option.