Store page fault loop when landing pads are enabled

[IkerGalardi]

Currently adding landing pad support to an operating system other than linux (https://github.com/IkerGalardi/zeptOS/pull/31/) and running into a page fault loop. The next are logs from qemu when interrupt logging is enabled:

riscv_cpu_do_interrupt: hart:0, async:0, cause:0000000000000012, epc:0x0000003ffffff09c, tval:0x0000000000000002, desc=reserved
riscv_cpu_do_interrupt: hart:0, async:0, cause:000000000000000f, epc:0x0000003ffffff00c, tval:0x0000003fffffe028, desc=store_page_fault
riscv_cpu_do_interrupt: hart:0, async:0, cause:000000000000000f, epc:0x0000003ffffff00c, tval:0x0000003fffffe028, desc=store_page_fault
riscv_cpu_do_interrupt: hart:0, async:0, cause:000000000000000f, epc:0x0000003ffffff00c, tval:0x0000003fffffe028, desc=store_page_fault
riscv_cpu_do_interrupt: hart:0, async:0, cause:000000000000000f, epc:0x0000003ffffff00c, tval:0x0000003fffffe028, desc=store_page_fault
riscv_cpu_do_interrupt: hart:0, async:0, cause:000000000000000f, epc:0x0000003ffffff00c, tval:0x0000003fffffe028, desc=store_page_fault
riscv_cpu_do_interrupt: hart:0, async:0, cause:000000000000000f, epc:0x0000003ffffff00c, tval:0x0000003fffffe028, desc=store_page_fault

Disabling landing pads makes everything work again so must be related to that. The first exception addres 0x3ffffff09c belongs to a fence.vma instruction. Next exceptions are simple stores to a structure saved in the scratch CSR (kernel context?).

Don't really know how to debug this. Tried using the file command on gdb but the firmware seems to be compiled using PIE or PIC so addresses are wrong. Could help debug this issue but I need some indications.

Used software:

• OpenSBI V1.6
• GDB Multiarch 15.2
• Qemu 9.2.3