Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Sebastian Huber <sebastian.huber@embedded-brains.de>
To: gdb-patches@sourceware.org
Cc: "Maciej W . Rozycki" <macro@orcam.me.uk>,
	Andrew Burgess <aburgess@redhat.com>
Subject: [PATCH v2 2/6] sim/mips: Do not abort on a HI/LO hazard
Date: Fri, 21 Aug 2026 05:23:00 +0200	[thread overview]
Message-ID: <20260821032304.293603-3-sebastian.huber@embedded-brains.de> (raw)
In-Reply-To: <20260821032304.293603-1-sebastian.huber@embedded-brains.de>

check_mf_hilo() calls sim_engine_abort() when a mfhi or mflo reads a
value which the ISA leaves UNPREDICTABLE.  The comment above the helper
states the rule correctly: the result is UNPREDICTABLE, not an error.
Reading an undefined value is not a fault, and the return value of the
helper is discarded at both call sites, so the abort is its only effect.

The abort halts the client and the run loop resumes it on the faulting
instruction, which reads the same register again and aborts again.  An
operating system may save HI and LO on interrupt entry and restore them
unchanged, so it reads them at an arbitrary instruction boundary where
the last writer is whatever the interrupted program did.  Every clock
tick landing in multiply or divide heavy code then deadlocks it.

Warn instead.

The warning repeats for every hazard.  Print it at most ten times.

Approved-By: Andrew Burgess <aburgess@redhat.com>
---
 sim/mips/mips.igen | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/sim/mips/mips.igen b/sim/mips/mips.igen
index 8203d19f8c4..3b52f2df43f 100644
--- a/sim/mips/mips.igen
+++ b/sim/mips/mips.igen
@@ -410,13 +410,26 @@
       && ! (peer->mf.timestamp > history->op.timestamp
 	    && peer->mf.timestamp < peer->mt.timestamp))
     {
+      static int warning_count = 0;
+
       /* The peer has been written to since the last OP yet we have
-         not */
-      sim_engine_abort (SD, CPU, CIA, "HILO: %s: MF at 0x%08lx following OP at 0x%08lx corrupted by MT at 0x%08lx\n",
-			itable[MY_INDEX].name,
-			(long) CIA,
-			(long) history->op.cia,
-			(long) peer->mt.cia);
+	 not.  The ISA makes the result of this MF UNPREDICTABLE, it does not
+	 make it an error.  An operating system may save HI and LO
+	 unconditionally on interrupt entry and restore them unchanged, so it
+	 reads whatever the interrupted program left behind.  Aborting the
+	 simulation here deadlocks such a system, since the run loop resumes at
+	 the faulting instruction and the MF is executed again.  */
+      if (warning_count < 10)
+	{
+	  ++warning_count;
+	  sim_io_eprintf (SD, "HILO: %s: MF at 0x%08lx following OP at 0x%08lx corrupted by MT at 0x%08lx\n",
+			  itable[MY_INDEX].name,
+			  (long) CIA,
+			  (long) history->op.cia,
+			  (long) peer->mt.cia);
+	  if (warning_count == 10)
+	    sim_io_eprintf (SD, "HILO: further warnings are silenced\n");
+	}
       ok = 0;
     }
   history->mf.timestamp = time;
-- 
2.51.0


  parent reply	other threads:[~2026-08-21  3:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21  3:22 [PATCH v2 0/6] sim: Fix MIPS livelocks and add software interrupts Sebastian Huber
2026-08-21  3:22 ` [PATCH v2 1/6] sim: Allow an overdue event to be descheduled Sebastian Huber
2026-08-21  3:23 ` Sebastian Huber [this message]
2026-08-21  3:23 ` [PATCH v2 3/6] sim/mips: Deliver the reserved instruction exception Sebastian Huber
2026-08-21  3:23 ` [PATCH v2 4/6] sim/mips: Check all interrupt enable conditions Sebastian Huber
2026-08-21  3:23 ` [PATCH v2 5/6] sim/mips: Keep the pending interrupts in Cause Sebastian Huber
2026-08-21  3:23 ` [PATCH v2 6/6] sim/mips: Recognise a software interrupt request Sebastian Huber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260821032304.293603-3-sebastian.huber@embedded-brains.de \
    --to=sebastian.huber@embedded-brains.de \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=macro@orcam.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox