From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux-mips@oss.sgi.com>
Subject: Sigcontext->sc_pc Passed to User
Date: Thu, 11 Jul 2002 11:08:21 +0200 [thread overview]
Message-ID: <00b401c228ba$88b29bf0$10eca8c0@grendel> (raw)
In responding to an enquiry from one of MIPS' third-party
software vendors, I noted something that seems a little
broken to me in the current (and maybe all historical)
MIPS/Linux kernels. Please forgive me for opening
old wounds if this has been beaten to death in the past.
When a user catches a signal, such as SIGBUS, the
signal "payload" includes a pointer to a sigcontext
structure on the stack, containing the state of the
CPU when the exception associated with the signal
occurred. But not exactly. We seem to consistently
call compute_return_epc() before send_sig() or
force_sig(). This results in the user being passed
an indication of the faulting PC that is one instruction
past the true location. That would be no problem,
except that the faulting instruction may have been
in a branch delay slot, such that there is no practical
and reliable way for the signal handler to determine
which instruction failed on the basis of the sigcontext
data.
It is, of course, important that execution resume
at the instruction following any instruction generating
an exception/signal. But that's not the same thing
as saying that the sigcontext should report the resumption
EPC instead of the faulting EPC. There are various
ways of dealing with this, but before going into any
of them, I'm curious as to whether this has been
discussed before, and whether anyone thinks that
things really should be the way they are.
Regards,
Kevin K.
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: linux-mips@oss.sgi.com
Subject: Sigcontext->sc_pc Passed to User
Date: Thu, 11 Jul 2002 11:08:21 +0200 [thread overview]
Message-ID: <00b401c228ba$88b29bf0$10eca8c0@grendel> (raw)
Message-ID: <20020711090821.49T3wkuojxFxv6lmBwcg-VOfg1magnaRPuQZ5BKw_ys@z> (raw)
In responding to an enquiry from one of MIPS' third-party
software vendors, I noted something that seems a little
broken to me in the current (and maybe all historical)
MIPS/Linux kernels. Please forgive me for opening
old wounds if this has been beaten to death in the past.
When a user catches a signal, such as SIGBUS, the
signal "payload" includes a pointer to a sigcontext
structure on the stack, containing the state of the
CPU when the exception associated with the signal
occurred. But not exactly. We seem to consistently
call compute_return_epc() before send_sig() or
force_sig(). This results in the user being passed
an indication of the faulting PC that is one instruction
past the true location. That would be no problem,
except that the faulting instruction may have been
in a branch delay slot, such that there is no practical
and reliable way for the signal handler to determine
which instruction failed on the basis of the sigcontext
data.
It is, of course, important that execution resume
at the instruction following any instruction generating
an exception/signal. But that's not the same thing
as saying that the sigcontext should report the resumption
EPC instead of the faulting EPC. There are various
ways of dealing with this, but before going into any
of them, I'm curious as to whether this has been
discussed before, and whether anyone thinks that
things really should be the way they are.
Regards,
Kevin K.
next reply other threads:[~2002-07-11 9:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-11 9:08 Kevin D. Kissell [this message]
2002-07-11 9:08 ` Sigcontext->sc_pc Passed to User Kevin D. Kissell
2002-07-11 13:17 ` Maciej W. Rozycki
2002-07-11 15:16 ` Kevin D. Kissell
2002-07-11 15:16 ` Kevin D. Kissell
2002-07-11 16:52 ` Maciej W. Rozycki
2002-07-12 1:40 ` Ralf Baechle
2002-07-12 8:00 ` Kevin D. Kissell
2002-07-12 8:00 ` Kevin D. Kissell
2002-07-12 10:00 ` Ralf Baechle
2002-07-12 11:49 ` Kevin D. Kissell
2002-07-12 11:49 ` Kevin D. Kissell
2002-07-12 15:29 ` Ralf Baechle
2002-07-12 13:01 ` Alan Cox
2002-07-12 13:01 ` Alan Cox
2002-07-12 14:23 ` Ralf Baechle
2002-07-12 15:36 ` Alan Cox
2002-07-12 15:36 ` Alan Cox
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='00b401c228ba$88b29bf0$10eca8c0@grendel' \
--to=kevink@mips.com \
--cc=linux-mips@oss.sgi.com \
/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