Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5765
`_ISR_Handler` of `cpukit/score/cpu/mips/cpu_asm.S` writes the exception program counter of the frame back to coprocessor 0 register 14 on one path alone. That path follows the call of `_Thread_Dispatch()`. The common exit, `_ISR_Handler_exit`, reaches `eret` with the register unchanged. A handler which changes the counter of the frame therefore has no effect on MIPS III and MIPS32. The `mips1` multilib hides the defect. Its exit loads the value into `k1` and returns with `j k1`, so the frame decides the address there. `mips_emulate_rdhwr_ulr()` of `bsps/mips/shared/irq/vectorexceptions.c` depends on that change. The 24Kf of Qemu leaves `Config3.ULRI` clear, so the user local register does not exist and `rdhwr` raises a reserved instruction exception. The handler supplies the thread pointer and advances the counter by four. On `mips/malta` the advance is lost and the instruction runs again. A trace of Qemu shows the same exception 11545896 times in eight seconds. `sptls01`, `sptls02`, `sptls04`, `ts-validation-tls-0` and `ts-validation-tls-1` hang. Write the exception program counter of the frame back in `_ISR_Handler_exit`. Set the exception level first, which the `eret` clears again. Found in the repair of the Malta BSP for the test suite. This description was created with Claude Code assistance. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5765 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-c0wd73efbpmbua3vzy44xz0fo-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
