Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>
Cc: Andrew Burgess <aburgess@redhat.com>,
	 gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 4/4] sim/mips: Recognise a software interrupt request
Date: Wed, 19 Aug 2026 14:17:01 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2608190240140.14132@angie.orcam.me.uk> (raw)
In-Reply-To: <1434207978.14132.1787099225217.JavaMail.zimbra@embedded-brains.de>

On Wed, 19 Aug 2026, Sebastian Huber wrote:

> >> Now clearly the `if` block is broken, we're setting PC from the wrong
> >> place I think.
> > 
> > Yep, the correct one would be ErrorEPC, unimplemented in sim AFAICT just
> > as proper support for status_ERL, which has numerous implications beyond
> > just ERET.
> 
> I this something I should address within my patch set or is moving the 
> check_interrupts() after the if/else block enough?

 I have glanced over your change and I conclude that the idea here is to 
call check_interrupts() whenever CP0 Status or Config registers have been 
changed such as to possibly raise a software interrupt.  Given how sim has 
been structured this seems a reasonable approach to me.  For this I think 
just moving the call past the block is exactly what is needed.

 Also check_interrupts() needs to be called from DERET emulation, since 
clearing CP0 Debug.DM (Debug_DM) also re-enables interrupts (subject to 
CP0 Status conditions), and Debug_DM needs to be checked against in 
`interrupt_requested'.

 FWIW I think this would best be called `software_interrupt_requested' or 
suchlike to avoid the ambiguity.  While one can read the comment, there's 
no need to force them doing so to figure out the intent.

 Then there's the preexisting issue with `interrupt_event' that does not 
check any of this beyond just CP0 Status.IE (status_IE).  While it seems 
broken to me anyway, as I fail to see a place where `interrupt_pending' 
would be set, let's not let breakage accumulate.  So I think bits from 
your `interrupt_requested' need to be factored out and used at both 
places, possibly as an introductory change.

 It's not clear to me how the argument to SignalExceptionInterrupt() is 
supposed to be used, but it's not interpreted anyway AFAICT, so let's just 
leave it as it is.

 As to adding proper support for ErrorEPC/status_ERL, you are obviously 
welcome to if you feel so inclined and in particular have a use for, but I 
wouldn't consider it a prerequisite for your patchset.  In real hardware 
it's a feature used primarily in the context of handling CPU soft reset, 
NMI and cache error exceptions, which I think are secondary ISA features 
when it comes to sim.

  Maciej

      reply	other threads:[~2026-08-19 13:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-16 23:43 [PATCH 0/4] Fix some MIPS GDB simulator issues Sebastian Huber
2026-08-16 23:43 ` [PATCH 1/4] sim: Allow an overdue event to be descheduled Sebastian Huber
2026-08-18  9:59   ` Andrew Burgess
2026-08-16 23:43 ` [PATCH 2/4] sim/mips: Do not abort on a HI/LO hazard Sebastian Huber
2026-08-18 10:04   ` Andrew Burgess
2026-08-16 23:43 ` [PATCH 3/4] sim/mips: Deliver the reserved instruction exception Sebastian Huber
2026-08-18 10:18   ` Andrew Burgess
2026-08-16 23:43 ` [PATCH 4/4] sim/mips: Recognise a software interrupt request Sebastian Huber
2026-08-18 10:42   ` Andrew Burgess
2026-08-18 11:45     ` Sebastian Huber
2026-08-19  0:03     ` Maciej W. Rozycki
2026-08-19  0:27       ` Sebastian Huber
2026-08-19 13:17         ` Maciej W. Rozycki [this message]

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=alpine.DEB.2.21.2608190240140.14132@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sebastian.huber@embedded-brains.de \
    /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