Lazy‑stacking enabled: S0‑S15 context risk in xPortPendSVHandler()

Kernel
1

Hello everyone,

When the lazy‑stacking feature (LSPEN=1) is enabled, I notice that the xPortPendSVHandler() context‑switch handler contains no explicit handling for the S0‑S15 floating‑point registers.

Here is my question:
Suppose Task A has executed floating‑point instructions. When a context switch to Task B takes place and the PendSV exception is triggered. With lazy stacking enabled, the hardware only reserves stack space for S0‑S15 on Task A’s stack frame, without actually storing the S0‑S15 register values to memory.

In the PendSV handler there is no separate action to trigger the real saving of S0‑S15. Does the instruction vstmdbeq r0!, {s16‑s31} trigger the lazy‑state‑preservation operation for S0‑S15?

If Task B also performs floating‑point operations after the switch, will this corrupt the floating‑point context of the suspended Task A?

2

Alternatively, I am wondering whether the execution of floating‑point instructions in Task B could trigger the actual saving of S0‑S15 for the previously‑suspended Task A. I am not certain about this behavior.

The reference materials I have reviewed only describe that lazy stacking takes place at exception entry time. Does executing floating‑point instructions in Task B trigger the completion of the lazy‑state preservation for Task A’s floating‑point context?

The reference materials I have reviewed only describe that lazy stacking takes place at exception entry time. Does executing floating‑point instructions in Task B trigger the completion of the lazy‑state preservation for Task A’s floating‑point context?-point operations will