Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AR: Define mcontrol* triggers and multiple accesses #883

Merged
merged 1 commit into from
Oct 4, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 21 additions & 6 deletions xml/hwbp_registers.xml
Original file line number Diff line number Diff line change
Expand Up @@ -378,6 +378,10 @@
though the load will not update its destination register. Debuggers
should consider this when setting such breakpoints on, for example,
memory-mapped I/O addresses.

If an instruction matches this trigger and the instruction performs
multiple memory accesses, it is \unspecified which memory accesses
have completed before the trigger fires.
</value>

<value v="1" name="after">
Expand Down Expand Up @@ -741,15 +745,23 @@
</value>

<value v="1" name="before">
The trigger fired just before the instruction that triggered it was
retired, but after all preceding instructions are retired.
The trigger fired before the instruction that matched it was
retired, but after all preceding instructions are retired. This
explicitly allows for instructions to be partially executed.
\Rxepc or \RcsrDpc (depending on \FcsrMcontrolSixAction) must be set
to the virtual address of the instruction that matched.

If a load operation matched and \FcsrMcontrolSixSelect=1 then a
memory access has been performed (including any side effects of
performing such an access) even though the load has not updated its
destination register.
An instruction that caused a trigger to fire might be executed
partially. In that case not all memory accesses may have been
performed, and some registers may not have been updated. Executing
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this trying to say that ALL registers will not have been updated, or that some registers may have been updated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to say that anything partial is OK, from 0% to 100%. E.g. if we had an instruction that pops 3 registers from the stack, any of those 3 registers (or none of them) may contain the new value. The important thing for the debugger is that nothing breaks if we now resume off that instruction by letting it execute again. (Can't account for non-idempotent memory, however.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gfavor Is this OK, or would you like to see the language tweaked more?

that instruction again must have the same result as fully executing
it the first time would have, except for any effects due to
non-idempotent memory. Implementations should avoid partial
instruction execution, but it might be unavoidable for instructions
that perform a large number of operations.

For vector instructions, the vstart mechanism can be used to handle
partial execution without duplicating memory accesses.
</value>

<value v="2" name="after">
Expand All @@ -766,6 +778,9 @@
\Rxepc or \RcsrDpc (depending on \FcsrMcontrolSixAction) must be set
to the virtual address of the next instruction that must be executed
to preserve the program flow.

If the instruction performed multiple memory accesses, all of them
have been completed.
</value>
</field>
<field name="select" bits="21" access="WARL" reset="0">
Expand Down