search

riscv-non-isa / riscv-trace-spec

RISC-V Processor Trace Specification
https://jira.riscv.org/browse/RVG-88
Creative Commons Attribution 4.0 International
152 stars 47 forks source link

Trace trigger hit when triggers with other action also fire #115

Open AoteJin opened 3 months ago

AoteJin commented 3 months ago

The debug spec says: "What happens with trace actions when triggers with different actions are also firing is left to the trace specification."

But I didn't find any related description in the e-trace spec.

Considering the case, a icount trigger is set to enter debug mode when a given PC 0x1234 is executed 100 times. Meantime, another trigger's action is configured to be trace-on at PC 0x1234. In this case, neither of the trigger should silence the other one and both should take effective. Otherwise, the user will witness one of trigger behaves as disabled.

I think we need to add clear definition to cover it.

AoteJin commented 3 months ago

Moreover, trace triggers should be orthogonal to each other, because theoretically, trace-on and trace-off trigger could hit at the same time.

IainCRobertson commented 3 months ago

There was a long discussion about this on the DTPM mailing list recently (subject was "Multiple trigger hit with different action" ). Issue #99 was generated in response to this. I believe this addresses your concern.

AoteJin commented 1 month ago

I went through the mail thread and it is addressing the action regarding trace on/off/notify. Actually what I am concerned about is the case when trigger set to action=1 ( enter debug mode) fires at the same time when another trigger set to trace related actions.

I would assume that the trace action (non-intrusive debug) should not suppress debug mode (intrusive debug) or vice verse.

Probably either debug spec or trace spec should elaborate on it?

IainCRobertson commented 1 month ago

That's a debug spec question, but I'd assume not also.

pdonahue-ventana commented 1 month ago

The debug spec says:

What happens with trace actions when triggers with different actions are also firing is left to the trace specification.

This sentence was added in 2018 and is unchanged from the Debug 0.13 spec that was ratified over 5 years ago (before E-Trace was ratified). It looks like there might have been a lack of coordination here.

AoteJin commented 1 month ago

@pdonahue-ventana do you suggest to open an issue in debug repo and close this one?

pdonahue-ventana commented 1 month ago

It's a strange and unfortunate situation. The debug spec came first and didn't know what trace wanted so it said that trace would answer the question. Debug got ratified. Trace didn't fill in the details and that got ratified without anybody noticing. The two options are to (1) put in some post-ratification clarification in the trace spec or (2) put something in the frozen but not quite ratified debug 1.0. Although the first option would also provide compatibility with debug 0.13, I don't think that we care about that in 2024. Option 2 makes the most sense. I assume that @IainCRobertson agrees.

As for the actual text that gets added, I think that there should be joint agreement between the trace and debug people. We don't want debug to dictate something that is bad for trace and vice-versa.

@rtwfroody

IainCRobertson commented 1 month ago

Actually, the statement Paul quoted from the Debug spec:

"What happens with trace actions when triggers with different actions are also firing is left to the trace specification"

Was not ignored or overlooked in the Trace specification. But the trace specification only addresses this in the context of triggers affecting trace: what happens if trace-on and trace-off occur together. It does not say anything about what happens to the debug functionality if a trigger directed towards debug happens at the same time as a trigger directed towards trace, and nor should it in my view. The debug functionality is described in the debug spec, and any clarification regarding how it responds to triggers originating from within the debug module has to be defined there.

Trace is essentially a passive functionality - the whole point is that it is non-intrusive. There is no mechanism defined in the debug spec or trace spec for trace to affect the behaviour of the debug module.

Iain

From: Paul Donahue @.> Sent: 26 July 2024 04:26 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>; Mention @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] Trace trigger hit when triggers with other action also fire (Issue #115)

It's a strange and unfortunate situation. The debug spec came first and didn't know what trace wanted so it said that trace would answer the question. Debug got ratified. Trace didn't fill in the details and that got ratified without anybody noticing. The two options are to (1) put in some post-ratification clarification in the trace spec or (2) put something in the frozen but not quite ratified debug 1.0. Although the first option would also provide compatibility with debug 0.13, I don't think that we care about that in 2024. Option 2 makes the most sense. I assume that @IainCRobertsonhttps://github.com/IainCRobertson agrees.

As for the actual text that gets added, I think that there should be joint agreement between the trace and debug people. We don't want debug to dictate something that is bad for trace and vice-versa.

@rtwfroodyhttps://github.com/rtwfroody

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/115#issuecomment-2251891151, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSSAJSW6MSR4IOM2JCTZOG6V3AVCNFSM6AAAAABI6GRWVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJRHA4TCMJVGE. You are receiving this because you were mentioned.Message ID: @.**@.>>

AoteJin commented 1 month ago

Intuitively, I agree on that the trace behavior should not affect the debug behavior. Since trigger itself is a module defined by debug spec, probably it is more adequate to elaborate on this case in scope of debug spec?

rtwfroody commented 1 month ago

Ideally we'd have a statement like "Triggers with debug actions (0, 1) exist completely independently of triggers with trace actions (2, 3, 4, 5). They have no effect on each other."

Questions:

  1. Is that backwards compatible?
  2. Do we need something similar for triggers with external trigger output actions (8, 9)?
pdonahue-ventana commented 2 weeks ago

@rtwfroody: Maybe a recommendation like this?

Triggers with actions in each of these three categories should exist completely independently of triggers with actions in each of the other categories:

  • debug actions (0, 1)
  • trace actions (2, 3, 4, 5)
  • external trigger output actions (8, 9)

Maybe actions 8 and 9 should even be independent of each other (making four categories) since you could signal both triggers at the same time. You can't trap and halt at the same time and you can't turn trace on and off and do a trace-notify at the same time.

rtwfroody commented 1 week ago

Or maybe we should just say that actions 0 and 1 are specified in our priority table. All others may fire simultaneously. I know the trace spec had a discussion about what it means when multiple ones fire at the same time, so they've already addressed that.

pdonahue-ventana commented 1 week ago

That's good.