RTEMS | cpukit/score/cpu/mips: The exception return ignores a changed program counter (#5765)

Sebastian Huber (@sebhub) gitlab at rtems.org
Fri Sep 11 07:33:22 UTC 2026



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260911/b793dd8a/attachment.htm>


More information about the bugs mailing list