`spike pk hello` does not terminate (32bit)
On macOS, I have built and installed the 32bit version of pk and of the riscv-gnu-toolchain.
I manage to compile programs using riscv32-unknown-elf-gcc, but when running spike -l path/to/pk32 hello, the script never stops, and if I halt it manually I get exception trap_instruction_access_fault.
I've looked for the problem online, and my impression is that the 32bit version of the toolchain is not really that stable. I haven't found a solution for my issue. Am I doing something wrong?
I'm seeing something similar with a 32-bit build - reverting this commit seems to fix the issue: https://github.com/riscv/riscv-pk/commit/5a0e3e55cab1d6f3462c77e852f16365c79f2c98
As far as I can tell from looking at the log generated by Spike, something appears to go wrong from that printm with pk ending up in trap_from_machine_mode after the ebreak instruction in htif_console_putchar - this then ends up in bad_trap which tries to print, which ends up in htif_console_putchar again which spins forever trying to acquire htif_lock.
@Generalbrus does commenting out the printm added in the above commit and rebuilding fix the issue for you?
I hadn't realised when I wrote my earlier comment that the things going wrong were probably due to lack of support for HTIF (and therefore printm) on rv32 - PR #94 created to try and workaround the issue.
@gmarkall I tried applying the edits in both commits but now I get trap_store_address_misaligned
I guess there's some other issue as well - does it get as far as printing "Hello" (assuming your hello program is intended to print "Hello")?
It loops indefinitely... The hello program is the one mentioned in the riscv-tools README to test everything is fine, it just prints "Hello World".
@gmarkall can you tell me what commands you used to install the 32-bit pk build with your edits, please? Tbh it's quite a mess to understand what the actual params for ./configure should be, given the recent changes and issues.
@Generalbrus I just used configure --prefix=<install path> --host=riscv32-unknown-elf because I already had a toolchain with rv32im as the default arch.
I also have this issue with the latest and removing the printm does in fact solve this issue.