RTEMS | bsps/mips: The exception vector publishes the frame in a global (#5752)

[Sebastian Huber (@sebhub)]

Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5752



`mips_vector_exceptions()` in `bsps/mips/shared/irq/vectorexceptions.c`
stores the exception frame in the global `mips_exception_frame` around
the call of `bsp_interrupt_handler_dispatch()`.
`bsp_interrupt_handler_default()` reads that global to tell an exception
which no handler consumed from a spurious interrupt. Commit
`7ec23f42d61` added it.

The global is a hidden argument of the dispatch. Two processors which
take an exception at the same time overwrite it, so the port cannot
support SMP in this form.

The exception vectors go through the interrupt manager because
`mips_gdb_stub_install()` in `bsps/mips/shared/gdbstub/mips-stub.c`
installs a handler on 18 of them. A fix must keep that stub working.

Give the MIPS port its own exception handler registration.
`ppc_exc_set_handler()` of the PowerPC port is the model. A handler
takes a `CPU_Exception_frame *` argument. Move the GDB stub to the new
call. Let the default handler call `rtems_fatal()` with
`RTEMS_FATAL_SOURCE_EXCEPTION` and the frame, which is what
`C_exception_handler()` of the PowerPC port does.

This changes the existing exception API of the MIPS port. A BSP or an
application which installs a handler on an exception vector with
`rtems_interrupt_handler_install()` must move to the new call.

The exception extensions are not part of this issue.

Found in the review of merge request !1401 by Kinsey Moore. This
description was created with Claude Code assistance.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5752
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-cn57l3xml225g461ph9ycmyk9-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/20260904/8d32e74e/attachment-0001.htm>