My Haiku RISC-V port progress

More applications are working. I made some hack to allow threads to exit. Before that threads attempted to directly return to kernel stack (arch_thread_enter_userspace) and failed because they have no permissions to read kernel stack or execure kernel code on return. I added _kern_exit_thread() in libroot.so and disabled signal handing on kernel side.

Proper implementation will need adding thread exit code in commpage.

Current thread stack looks like this:

Thread 336 "VirtIO tablet watcher" running on CPU 0
Stack:
FP: 0x807e4a60, PC: <kernel_riscv64> debug_call_with_fault_handler.localalias.7 + 121
FP: 0x807e4af0, PC: <kernel_riscv64> _ZL20kernel_debugger_loopPKcS0_Pvi + 251
FP: 0x807e4b60, PC: <kernel_riscv64> _ZL24kernel_debugger_internalPKcS0_Pvi + 131
FP: 0x807e4ba0, PC: <kernel_riscv64> panic + 93
FP: 0x807e4c40, PC: <kernel_riscv64> user_debug_exception_occurred + 31
FP: 0x807e4d30, PC: <kernel_riscv64> vm_page_fault + 421
FP: 0x807e4e20, PC: <kernel_riscv64> STrap + 571
FP: 0x807e4f20, PC: <kernel_riscv64> SVecU + 109 /* supervisor trap handler for user mode, it switches environment from user to kernel and back, written in assembly */
FP: 0xffffffdb32753fe0, PC: <virtio> _ZN13VirtioHandler7WatcherEPv + 17
FP: 0xffffffdb32754000, PC: <libroot.so> _thread_do_exit_work + 107 /* actually this is <libroot.so> thread_entry */
FP: 0x807e4f50, PC: <kernel_riscv64> arch_thread_enter_userspace + 161 /* everybody knows what happens if user thread attempt to return here :) */
FP: 0x807e4f90, PC: <kernel_riscv64> _ZL15enter_userspacePN7BKernel6ThreadEP24UserThreadEntryArguments + 67
FP: 0x807e4fb0, PC: <kernel_riscv64> _ZL19common_thread_entryPv + 77
FP: 0x0, PC: <kernel_riscv64> arch_thread_entry + 3

screenshot50

19 Likes