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
prev parent 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