From 5f4a2f20321be7da75f395db29e03c09fec09ec9 Mon Sep 17 00:00:00 2001 From: Tim Newsome Date: Mon, 9 Oct 2023 09:36:40 -0700 Subject: [PATCH] AR: Clarify itrigger behavior. Specifically, make clear that itrigger fires *after* the original exception has finished updating all the CSRs. Hopefully resolves #890. --- xml/hwbp_registers.xml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/xml/hwbp_registers.xml b/xml/hwbp_registers.xml index 9ebf2df0..1df15e0a 100755 --- a/xml/hwbp_registers.xml +++ b/xml/hwbp_registers.xml @@ -1145,11 +1145,13 @@ interrupt. (E.g.\ it does not fire when a timer interrupt occurs but that interrupt is not enabled in \Rmie.) - When the trigger fires, all CSRs are updated for the interrupt trap as defined by the - Privileged Spec, and the requested action is taken just before the - first instruction of the trap handler is executed. - If the trigger fires with \FcsrItriggerAction=0 then zero is written to the - {\tt tval} CSR on the breakpoint trap (see ~\ref{sec:nativetrigger}). + When the trigger matches, it fires after the trap occurs, just before + the first instruction of the trap handler is executed. If + \FcsrItriggerAction=0, the standard CSRs are updated for taking the + breakpoint trap, and zero is written to the relevant {\tt tval} CSR. If + the breakpoint trap does not go to a higher privilege mode, this will + lose CSR information for the original trap. See + Section~\ref{sec:nativetrigger} for more information about this case. If \RcsrTextraThirtytwo or \RcsrTextraSixtyfour are implemented for this trigger, it only matches when the conditions set there are satisfied.