RTEMS | score/cpu/riscv: A synchronous exception overwrites the stack of the trapped context (#5809)

[Sebastian Huber (@sebhub)]

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

Assignee: Sebastian Huber

## Summary

The RISC-V CPU port has these defects:

- The entry of a synchronous exception reserves space for the interrupt
  frame only. It stores the rest of the exception frame above the stack
  pointer of the trapped context. On RV64 with the D extension, it
  overwrites 208 bytes of the stack of the trapped context.

- The port provides no `_CPU_Exception_resume()`. A fatal error extension
  which receives an exception frame cannot continue the trapped context.

- No validation test checks the context switch, the interrupt processing or
  the exception resume of the port.

## Proposal

Move the interrupt frame to the end of the exception frame. The path of a
synchronous exception then lowers the stack pointer by the size of the
other members. The interrupt path keeps its frame size. On RV32, the
interrupt frame needs padding to the stack alignment.

Add `_CPU_Exception_resume()`.

Add validation tests which load a pattern into every register which the
port has to preserve, and compare what arrives. The interrupt test lets its
handler overwrite every call-used register and `fcsr`. Each test proves
that each of its checks can fail. It runs its scenario once per register
with the pattern of that register inverted, and requires that exactly the
checks of that register fail.

This description was created with Claude Code assistance.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5809
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/6-ehnzl27ttd45pak03oc4v9k5n-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/20261012/59f760d1/attachment-0001.htm>