Multiple trigger hit with different action

111 views
Skip to first unread message

Deepak Panwar

unread,
Jun 8, 2018, 3:27:21 PM6/8/18
to RISC-V Debug Group
Hi,

Each trigger has an action associated with it which is specified in the mcontrol register (like going to debug mode or taking a breakpoint exception). However, it isn't specified what should happen if two or more triggers hit simultaneously and they have different actions. Should that be considered an illegal case or trigger module should follow a specific priority in that case? Will be nice to add clarify this case in the debug spec.

Thanks,
Deepak

Bruce Ableidinger

unread,
Jun 8, 2018, 8:12:06 PM6/8/18
to RISC-V Debug Group, Deepak Panwar
In the implementations I have done (which includes logic analyzers) a hw precedence is defined so there is no ambiguity or illegal outcomes. But to complicate it a bit, what if both a Start trace and Stop trace occur at the same time. Should the action differ depending on the current trace state? Or should Start trace always take precedence over Stop?

  ---- Bruce

From: Deepak Panwar <panwar...@gmail.com>
Sent: Friday, June 8, 2018 12:27:21 PM
To: RISC-V Debug Group
Subject: [debug] Multiple trigger hit with different action
 
--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/b6da65ca-504c-4c09-8bce-2fbd118e4cdd%40groups.riscv.org.

Tim Newsome

unread,
Jun 8, 2018, 10:49:11 PM6/8/18
to Deepak Panwar, RISC-V Debug Group
The trace actions are completely orthogonal to the debug exception/enter debug mode actions. Since there is a separate trace working group, I suggest leaving the priority (if any) of those actions up to that group.

That just leaves "breakpoint exception" and "enter debug mode." These actions could both be taken by making all changes required to take a breakpoint exception, not executing any instructions there, and then entering Debug Mode. If that's too much to expect from the hardware, I'd like "enter debug mode" to take precedence, so that a running program cannot affect debugging.

Hardware designers, what do you think?

Tim

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

Deepak Panwar

unread,
Jun 11, 2018, 12:52:06 PM6/11/18
to RISC-V Debug Group, panwar...@gmail.com
I think both implementation are acceptable from the hardware perspective. It's probably better to give higher priority to one though (debug mode). Should this be added to the debug spec?

Thanks,
Deepak


On Friday, June 8, 2018 at 9:49:11 PM UTC-5, Tim Newsome wrote:
The trace actions are completely orthogonal to the debug exception/enter debug mode actions. Since there is a separate trace working group, I suggest leaving the priority (if any) of those actions up to that group.

That just leaves "breakpoint exception" and "enter debug mode." These actions could both be taken by making all changes required to take a breakpoint exception, not executing any instructions there, and then entering Debug Mode. If that's too much to expect from the hardware, I'd like "enter debug mode" to take precedence, so that a running program cannot affect debugging.

Hardware designers, what do you think?

Tim
On Fri, Jun 8, 2018 at 12:27 PM, Deepak Panwar <panwar...@gmail.com> wrote:
Hi,

Each trigger has an action associated with it which is specified in the mcontrol register (like going to debug mode or taking a breakpoint exception). However, it isn't specified what should happen if two or more triggers hit simultaneously and they have different actions. Should that be considered an illegal case or trigger module should follow a specific priority in that case? Will be nice to add clarify this case in the debug spec.

Thanks,
Deepak

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

Tim Newsome

unread,
Jun 16, 2018, 2:25:34 PM6/16/18
to Deepak Panwar, RISC-V Debug Group

On Mon, Jun 11, 2018 at 9:52 AM, Deepak Panwar <panwar...@gmail.com> wrote:

I think both implementation are acceptable from the hardware perspective. It's probably better to give higher priority to one though (debug mode). Should this be added to the debug spec?

If they’re both acceptable, I much prefer both actions to happen. That way the debugger still has control, but a trigger that software is expecting to fire still gets to fire. I’m thinking:

When a trigger with the “enter Debug Mode” action and another trigger with
“raise a breakpoint exception” action fire at the same time, both actions are
taken. It is implementation-dependent which of the two happens first. What
happens with trace actions in such a case is left to the trace spec.

Tim

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

Deepak Panwar

unread,
Jun 19, 2018, 4:38:42 PM6/19/18
to RISC-V Debug Group, panwar...@gmail.com
Hi Tim,

Our current implementation gives higher priority to Debug Mode. However, what you are suggesting should be acceptable. Please add it to the spec.

Thanks,
Deepak

Tim Newsome

unread,
Jun 19, 2018, 5:25:23 PM6/19/18
to Deepak Panwar, RISC-V Debug Group

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/dce3a020-af27-43ec-a15e-762efe61975e%40groups.riscv.org.

Deepak Panwar

unread,
Jun 26, 2018, 6:13:00 PM6/26/18
to RISC-V Debug Group, panwar...@gmail.com
Hi Tim,

Once the core takes a breakpoint exception due to trigger, it will be nice to have a mechanism to disable all the triggers till the core is in the exception handler. There might be cases when we don't want to hit any triggers while in the exception handler (this is especially true with icount trigger). One way to do it is to have a trigger enable/disable bit in one of the CSR registers. Hardware can set this bit when it takes the breakpoint exception. Software can reset the bit at the end of the handler. Any other solution is also fine as long as we can control triggers inside the exception.

Thanks,
Deepak

Megan Wachs

unread,
Jun 26, 2018, 7:28:55 PM6/26/18
to Deepak Panwar, RISC-V Debug Group
this almost sounds like you want “breakpoint exception” to act more like an interrupt, because then everything you are asking for can be handled by the existing interrupt mechanisms from the ISA spec. So perhaps a better thing would be to define a new action which is to raise a nonstandard interrupt (not sure how to define what that interrupt number should be)

--
Megan A. Wachs
Engineer | SiFive, Inc 
1875 South Grant Street
Suite 600
San Mateo, CA 94402

Tim Newsome

unread,
Jun 26, 2018, 7:59:44 PM6/26/18
to Deepak Panwar, RISC-V Debug Group
On Tue, Jun 26, 2018 at 3:13 PM, Deepak Panwar <panwar...@gmail.com> wrote:
Hi Tim,

Once the core takes a breakpoint exception due to trigger, it will be nice to have a mechanism to disable all the triggers till the core is in the exception handler. There might be cases when we don't want to hit any triggers while in the exception handler (this is especially true with icount trigger). One way to do it is to have a trigger enable/disable bit in one of the CSR registers. Hardware can set this bit when it takes the breakpoint exception. Software can reset the bit at the end of the handler. Any other solution is also fine as long as we can control triggers inside the exception.

Isn't it enough that you can set triggers only on specific modes? Eg. a trigger hit in U mode will change to M mode (presumably) when the exception is taken.

For icount, it says "When count is decremented to 0, the trigger fires." I meant that to say that if the count goes from 1 to 0, the trigger fires. If it's already 0 then it does not fire, so this trigger will only fire once until it's manually reset.

What you suggest seems reasonable (although Megan's twist makes a bit more sense, perhaps), but I'm wary of adding more features at this point, so I'm trying to see how you can best accomplish with what already exists.

Tim
 
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

bruce.ableidinger

unread,
Jun 26, 2018, 8:36:30 PM6/26/18
to Tim Newsome, Deepak Panwar, RISC-V Debug Group

Deepac,

 

I’m a bit confused.  4.1 of the spec says about Debug Mode:

 

2. All interrupts (including NMI) are masked.

3. Exceptions don't update any registers. That includes cause, epc, tval, dpc, and mstatus.

They do end execution of the Program Buffer.

4. No action is taken if a trigger matches.

 

Doesn’t #4 resolve your question?

 

If the issue is the small amount of time between the trigger signal going true and the exception handler being entered, then hardware should lock out other triggers, exceptions, interrupts.  It shouldn’t be a user-programmable choice (IMO).

If this is a case of wanting to “debug the debugger” I think the code running at the debug level has to be written correctly and doesn’t need to be debugged.

 

--- Bruce

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

Deepak Panwar

unread,
Jun 26, 2018, 11:13:11 PM6/26/18
to RISC-V Debug Group, panwar...@gmail.com
Hi Tim,

Our core has only one mode (machine mode) and I assume that's pretty common for lot of embedded cores. So, setting the trigger only on specific modes doesn't work for us. Megan is right in a sense that we want something similar to interrupts. However, we will prefer hardware to disable the triggers while entering the breakpoint exception to make sure not a single instruction execute in the handler with triggers enabled. 

Regarding icount, I was talking about the case when core enters the breakpoint exception due to address/data trigger and then hit the icount trigger inside the handler.

Thanks,
Deepak

Deepak Panwar

unread,
Jun 26, 2018, 11:21:14 PM6/26/18
to RISC-V Debug Group, t...@sifive.com, panwar...@gmail.com
Hi Bruce,

Core will not enter the debug mode if the trigger action is set to 0. In that case, we will go to the breakpoint exception and can hit other triggers in the handler unless there is a way to disable them.

-Deepak

Tim Newsome

unread,
Jun 27, 2018, 3:23:24 PM6/27/18
to Deepak Panwar, RISC-V Debug Group
Hi Deepak,

Thanks for explaining again. I know understand the problem. Specifically you're worried about something like this:
1. 2 triggers are set
2. Trigger 1 fires, and causes a debug exception.
3. The debug exception code runs a bit, presumably saving registers.
4. Trigger 2 fires, causing another debug exception.

Now the original PC where Trigger 1 fired is lost, and it's likely not possible to restore the registers that were already saved as well.

I don't have an answer for this with the current spec, aside from "be careful setting triggers." Avoiding the problem is doable, but it is a hassle and surely somebody will get bit by it.

Now I'm torn between pushing the ratification process forward, and adding one more feature. This feels like a bug, but it takes more than a tiny tweak to solve it. What does everybody else think?

Tim

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/c5b00f2c-2375-4c87-abc8-f3d84a93a9fd%40groups.riscv.org.

Joe Rahmeh

unread,
Jun 28, 2018, 11:00:48 AM6/28/18
to RISC-V Debug Group, panwar...@gmail.com
Hi Tim, Deepak,

Once we consider external interrupts, avoiding the problem (of clobbering the mepc) is not possible.  Consider the case where the icount trigger is set to 1 (debugger is using icount to single step instructions) and an external interrupt takes place, the icount trigger will trip on the first instruction in the external interrupt handler causing the loss of the mepc.  A very similar scenario can happen if a store data trigger is set and a timer interrupt takes place, the interrupt handler may match the store data trigger while trying to save the mepc which causes an exception that clobbers the mepc. It looks like there should be a trigger exception enable bit that gets cleared automatically on any interrupt/exception so that it is not possible to cause a trigger-exception while a handler is in the process of saving state.  The handler can re-enable trigger exceptions once it is safe to do so.  Basically, we would need an mte (machine trigger enable) and a mpte (machine previous trigger enable) in mstatus or some other CSR.
 
Joe

Megan Wachs

unread,
Jun 28, 2018, 11:28:37 AM6/28/18
to Tim Newsome, Deepak Panwar, RISC-V Debug Group
Tim I don’t understand your example:

On Wed, Jun 27, 2018 at 12:23 Tim Newsome <t...@sifive.com> wrote:
Hi Deepak,

Thanks for explaining again. I know understand the problem. Specifically you're worried about something like this:
1. 2 triggers are set
2. Trigger 1 fires, and causes a debug exception.

What is a “debug exception” here? Do you mean entry into debug mode, or do you mean “breakpoint exception” (no external debugger is present)? 

3. The debug exception code runs a bit, presumably saving registers.
4. Trigger 2 fires, causing another debug exception.

Now the original PC where Trigger 1 fired is lost, and it's likely not possible to restore the registers that were already saved as well.

This is a problem with all nested interrupts. For interrupts it’s dealt with because the hardware turns off interrupts until explicitly turned on again by the handler.


I don't have an answer for this with the current spec, aside from "be careful setting triggers." Avoiding the problem is doable, but it is a hassle and surely somebody will get bit by it.

Again, this is a issue dealt with by interrupt hardware already, to me this seems like a problem in defining triggers as only causing exceptions, not interrupts. Exceptions aren’t supposed to be “disableable”, interrupts are and already have the appropriate functionality defined (and even more nesting functionality is being defined by the fast interrupts working group).


Now I'm torn between pushing the ratification process forward, and adding one more feature. This feels like a bug, but it takes more than a tiny tweak to solve it. What does everybody else think?

How quickly does “be careful setting triggers” break down? Is this a real problem in practice? 

Also, Is there reference software that uses icount trigger successfully? I don’t see how using icount as a single step can possibly work in a system with only ONE mode (counting debug as a mode). If you want to use m-mode handler to single step through m-mode code with icount triggers, I don’t see how that would ever work, but perhaps I am misunderstanding what deepak is worried about.



Tim

--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

Megan Wachs

unread,
Jun 28, 2018, 11:31:25 AM6/28/18
to Joe Rahmeh, RISC-V Debug Group, panwar...@gmail.com
I think what joe is saying matches what I’m saying about trigger exceptions being something like interrupts that you can turn on and off. Do you really need something MORE than that? Why do we need special mpte vs mpe?

Joe Rahmeh

unread,
Jun 28, 2018, 1:21:12 PM6/28/18
to Megan Wachs, RISC-V Debug Group, panwar...@gmail.com
HI Megan,

Yes, trigger exceptions are similar to interrupts.  However, interrupts are automatically disabled by the hardware as soon as an interrupt/exception is taken.  With interrupts disabled, the interrupt handler can safely save the mepc and other state and then re-enable interrupts if it wishes to do so. There is currently no automatic disabling of triggers when an interrupt/exception is taken.  Consequently there is a race condition: a trigger may cause an additional exception before the currently executing trap handler has a chance to save the mepc and other hart state.  If this happens, then the mepc of the original exception is lost and there is no way to recover it.

There is currently no way for software to guard against this loss of state.  If we think of triggers as similar to interrupts, then we need a similar mechanism to automatically disable trigger exceptions when a trigger/exception is taken.

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

Megan Wachs

unread,
Jun 28, 2018, 2:14:07 PM6/28/18
to Joe Rahmeh, RISC-V Debug Group, panwar...@gmail.com
Right, I understand that as currently defined there is no way to do what you want. I’m just asking if there were an additional trigger action defined (not currently in the spec) which raised a certain sort of interrupt instead of breakpoint exception, does that have the functionality you want. Because what you describe to me sounds exactly how RISC-V interrupts are defined.

Joe Rahmeh

unread,
Jun 28, 2018, 5:58:37 PM6/28/18
to Megan Wachs, RISC-V Debug Group, Deepak Panwar
Hi Megan,

There is no additional trigger action that we are defining.  We are trying to follow the spec.  We found a couple of scenarios that make debug triggers unusable if we implement them according to the spec.

Here is one scenario:

1. Software defines a store data debug trigger with an equality match, a "before" timing,  and a target value of 0x80000000  (if a store tries to write 0x80000000, we want a breakpoint exception).

2. Before the trigger is tripped, we encounter an external interrupt.

3. The external interrupt handler tries to save the mepc register to memory.  The mepc happens to have 0x8000000 in it.  This trips our store trigger before the store is done. The store does not happen (mepc is not saved) and we take an exception which writes mepc.  When we handle the trigger exception and return to the external interrupt handler to replay the instruction that is attempting to store mepc, the mepc is no longer valid.  There is no way to recover the original mepc.  Now when we return from the external interrupt, we are no longer returning to the originally interrupted instruction.  We broke the ISA.

A scenario similar to the above happened on the first batch of (random) tests we ran after we implemented the spec with 4 triggers.

Unless there is an automatic blocking of triggers when an exception/interrupt is taken, there is no way to guarantee that a trigger will not trip in the middle of exception/interrupt handling code before such code had a chance to save important registers.

Joe



To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

Tim Newsome

unread,
Jun 28, 2018, 6:25:51 PM6/28/18
to Joe Rahmeh, Megan Wachs, RISC-V Debug Group, Deepak Panwar

I think everybody understands the problem at this point.

Megan’s solution sounds sensible to me:
Instead of having a trigger action cause a debug exception, instead have it cause a debug interrupt. There is no such thing as a debug interrupt currently, but it would behave the same as any other interrupt that traps to machine mode. The regular interrupt handler would save registers, look at possible interrupt sources (now including triggers), and handle them appropriately.

This is a change we would have to make to the Debug Specification.

So in the scenario Joe just outlined:

    1. Software defines a store data debug trigger with an equality match, a “before” timing, and a target value of 0x80000000 (if a store tries to write 0x80000000, we want a breakpoint exception).

    1. Before the trigger is tripped, we encounter an external interrupt.

    2. The external interrupt handler tries to save the mepc register to memory. The mepc happens to have 0x8000000 in it. This trips the store trigger, which raises an interrupt, but interrupts are already disabled because we’re in an interrupt handler. When interrupts become enabled (I think) the interrupt will be taken at that time. (I’m not 100% sure how RISC-V handles interrupts that fire during an interrupt handler, but presumably it’s reasonable behavior, and the same would apply here.)

    Tim

    ​

    --
    You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
    To post to this group, send email to de...@groups.riscv.org.
    Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
    To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAPQuH8S9%2B89XM%3Ds4myic-m%2BPHd8U%2BbcWOA_G361%3DByn1Zk5HfA%40mail.gmail.com.

    Megan Wachs

    unread,
    Jun 28, 2018, 7:02:14 PM6/28/18
    to Tim Newsome, Deepak Panwar, Joe Rahmeh, RISC-V Debug Group
    On Thu, Jun 28, 2018 at 15:25 Tim Newsome <t...@sifive.com> wrote:

    I think everybody understands the problem at this point.

    Megan’s solution sounds sensible to me:
    Instead of having a trigger action cause a debug exception, instead have it cause a debug interrupt. There is no such thing as a debug interrupt currently, but it would behave the same as any other interrupt that traps to machine mode. The regular interrupt handler would save registers, look at possible interrupt sources (now including triggers), and handle them appropriately.

    This is a change we would have to make to the Debug Specification.

    So in the scenario Joe just outlined:

      1. Software defines a store data debug trigger with an equality match, a “before” timing, and a target value of 0x80000000 (if a store tries to write 0x80000000, we want a breakpoint exception).

      1. Before the trigger is tripped, we encounter an external interrupt.

      2. The external interrupt handler tries to save the mepc register to memory. The mepc happens to have 0x8000000 in it. This trips the store trigger, which raises an interrupt, but interrupts are already disabled because we’re in an interrupt handler. When interrupts become enabled (I think) the interrupt will be taken at that time. (I’m not 100% sure how RISC-V handles interrupts that fire during an interrupt handler, but presumably it’s reasonable behavior, and the same would apply here.)


      It’s sort of reasonable but probably not what you want... most interrupt inputs to mip are expected to be level interrupts (once set, they stay set until cleared by SW writes to various other registers). So the trigger unit would have to have the same level behavior, which means we would ALSO have to define a way to clear it down if you wanted the trigger interrupt to be taken later. But it seems like you would not want it taken later, if you did, the analogy to an interrupt doesn’t hold because the mepc that would be recorded would be whatever the instruction was after you enabled triggers again, not the actual triggered pc from before.  

      The interrupt idea is mostly brainstorming and attempting to not reinvent the wheel if the ISA already suggests a solution. There is a proposal for fine grained interrupt nesting and prioritization and maybe this issue should be addressed there vs special bits for triggers in particular. 

      Megan 

      Tim Newsome

      unread,
      Jun 28, 2018, 9:18:23 PM6/28/18
      to Megan Wachs, Deepak Panwar, Joe Rahmeh, RISC-V Debug Group

      On Thu, Jun 28, 2018 at 4:02 PM, Megan Wachs <me...@sifive.com> wrote:


      On Thu, Jun 28, 2018 at 15:25 Tim Newsome <t...@sifive.com> wrote:

      I think everybody understands the problem at this point.

      Megan’s solution sounds sensible to me:
      Instead of having a trigger action cause a debug exception, instead have it cause a debug interrupt. There is no such thing as a debug interrupt currently, but it would behave the same as any other interrupt that traps to machine mode. The regular interrupt handler would save registers, look at possible interrupt sources (now including triggers), and handle them appropriately.

      This is a change we would have to make to the Debug Specification.

      So in the scenario Joe just outlined:

        1. Software defines a store data debug trigger with an equality match, a “before” timing, and a target value of 0x80000000 (if a store tries to write 0x80000000, we want a breakpoint exception).

        1. Before the trigger is tripped, we encounter an external interrupt.

        2. The external interrupt handler tries to save the mepc register to memory. The mepc happens to have 0x8000000 in it. This trips the store trigger, which raises an interrupt, but interrupts are already disabled because we’re in an interrupt handler. When interrupts become enabled (I think) the interrupt will be taken at that time. (I’m not 100% sure how RISC-V handles interrupts that fire during an interrupt handler, but presumably it’s reasonable behavior, and the same would apply here.)


        It’s sort of reasonable but probably not what you want... most interrupt inputs to mip are expected to be level interrupts (once set, they stay set until cleared by SW writes to various other registers). So the trigger unit would have to have the same level behavior, which means we would ALSO have to define a way to clear it down if you wanted the trigger interrupt to be taken later. But it seems like you would not want it taken later, if you did, the analogy to an interrupt doesn’t hold because the mepc that would be recorded would be whatever the instruction was after you enabled triggers again, not the actual triggered pc from before.  

        The interrupt level could be controlled by the hit bits in each trigger. (While hit is set, the interrupt is high.) That gets you level semantics without really much change, and an existing way to clear the interrupt.

        You do have an issue that you lose the PC at the time that the interrupt fired. I don’t really see any way around that short of adding another pc register. I doubt that’s worth it, since this is really only a problem in harts that only support M mode, which presumably are trying to be tiny.

        An interrupt handler would look like:

        1. Save registers
        2. Handle interrupts
        3. Clear hit in every trigger
        4. Restore registers
        5. mret

        Steps 3 and 4 might cause triggers to fire, depending on what triggers are set. In that case the interrupt handler will be started again immediately after step 5, and this cycle could continue forever. That sounds terrible, on the other hand, users shouldn’t set triggers like that. In an M mode only system, programs can also access memory anywhere and cause a system to hang that way.

        This problem could be avoided altogether by requiring that triggers whose action=0 don’t fire at all when the interrupt they would cause is currently disabled. (Triggers that are used by an external debugger still would fire, so that interrupt handlers can be debugged that way.)

        Tim

        ​

        Megan Wachs

        unread,
        Jun 28, 2018, 11:47:27 PM6/28/18
        to Tim Newsome, Deepak Panwar, Joe Rahmeh, RISC-V Debug Group
        Yeah, but that again sort of breaks the interrupt analogy, because now you have a dependency on the hit logic back from mie&mstatus registers, which is weird. 

        “Users shouldn’t set triggers like that”... again, that’s sort of the point. What is the point of a data match trigger on its own? I assumed that would generally be chained with an address match trigger, eg “tell me when i write “valid” to the “UART TX” register. why would you say “I wanted to know when I wrote 8000_0000 anywhere in memory”.? My read of Joe’s email is that they hit this in randomized testing, or was it a real debugging situation?

        Tim

        ​

        --
        You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
        To post to this group, send email to de...@groups.riscv.org.
        Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

        Joe Rahmeh

        unread,
        Jun 29, 2018, 10:48:06 AM6/29/18
        to Megan Wachs, Tim Newsome, Deepak Panwar, RISC-V Debug Group
        Hi Megan,

        The example is contrived and it did come from randomized testing.  It is still a valid example. With respect to usefulness, there is no difference between the store trigger example and something like "mul x0, x1, x2".

        Joe


        Tim

        ​
        To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.

        To post to this group, send email to de...@groups.riscv.org.
        Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.

        Tim Newsome

        unread,
        Jun 29, 2018, 2:07:19 PM6/29/18
        to Joe Rahmeh, Megan Wachs, Deepak Panwar, RISC-V Debug Group

        Here’s a real example: setting a memory access trigger on the address just below the stack, to catch programs that blow through their stack. If a program is right on the edge when an interrupt fires, this trigger might fire when registers are saved/restored by the interrupt handler, which leads to exactly the problem I detailed. It will be rare, but this discussion is not entirely academic.

        Having the trigger logic depend on mie/mstatus is a bit awkward, but the trigger logic already knows the current execution mode. This doesn’t feel terribly different. How else could we fix this? I think the crux is that we want to re-enable triggers when mret is executed. A CSR that we write 0 to to enable triggers could work. That way the CSR can be written as the last instruction before mret, so unless the trigger fires on execution of mret there will be no problem.

        Tim

        ​

        Tim

        ​
        To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.

        To post to this group, send email to de...@groups.riscv.org.
        Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
        Reply all
        Reply to author
        Forward
        0 new messages