Change Details

The coredump logic calls get_arm64_sve twice: once to get the note size, and once to get the data. The note size calculation depended on the volatile `PCB_FP_SVEVALID` flag. If this flag was cleared between the two calls (e.g., due to a context switch clearing the flag to comply with the ABI), the second call would expect a smaller buffer size than the first, triggering a KASSERT panic ("invalid size"). Fix this by ensuring the state is saved to the PCB before we decide which format to use and removing the volatile flag check. Using `pcb->pcb_svesaved != NULL` is a stable indicator of SVE usage. PR: 292195

The coredump logic calls get_arm64_sve twice: once to get the note size, and once to get the data. The note size calculation depended on the volatile `PCB_FP_SVEVALID` flag. If this flag was cleared between the two calls (e.g., due to a context switch clearing the flag to comply with the ABI), the second call would expect a smaller buffer size than the first, triggering a KASSERT panic ("invalid size"). Fix this by ensuring the SVE state is saved to the PCB before we decide whether to use SVE or VFP. PR: 292195

The coredump logic calls get_arm64_sve twice: once to get the note size, and once to get the data. The note size calculation depended on the volatile `PCB_FP_SVEVALID` flag. If this flag was cleared between the two calls (e.g., due to a context switch clearing the flag to comply with the ABI), the second call would expect a smaller buffer size than the first, triggering a KASSERT panic ("invalid size"). Fix this by ensuring the SVE state is saved to the PCB before we decide which format to use and removing the volatile flag check. Using `pcb->pcb_svesaved != NULL` is a stable indicator of SVE usagewhether to use SVE or VFP. PR: 292195