From: David Howells <dhowells@redhat.com>
To: akpm@osdl.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] FRV update the trap tables comment
Date: Tue, 14 Dec 2004 16:34:19 +0000 [thread overview]
Message-ID: <9801.1103042059@redhat.com> (raw)
The attached patch updates the FRV trap tables comment to make it more
appropriate.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat frv-trap-comment-2610rc3.diff
entry-table.S | 40 +++++++++++++++++++++++++++++-----------
1 files changed, 29 insertions(+), 11 deletions(-)
diff -uNr linux-2.6.10-rc3-mm1-mmcleanup/arch/frv/kernel/entry-table.S linux-2.6.10-rc3-mm1-misc/arch/frv/kernel/entry-table.S
--- linux-2.6.10-rc3-mm1-mmcleanup/arch/frv/kernel/entry-table.S 2004-12-13 17:33:50.000000000 +0000
+++ linux-2.6.10-rc3-mm1-misc/arch/frv/kernel/entry-table.S 2004-12-13 19:28:04.000000000 +0000
@@ -17,19 +17,37 @@
###############################################################################
#
-# declare the main trap and vector tables
+# Declare the main trap and vector tables
#
-# - the first instruction in each slot is a branch to the appropriate
-# kernel-mode handler routine
+# There are six tables:
#
-# - the second instruction in each slot is a branch to the debug-mode hardware
-# single-step bypass handler - this is called from break.S to deal with the
-# CPU stepping in to exception handlers (particular where external interrupts
-# are concerned)
-#
-# - the linker script places the user mode and kernel mode trap tables on to
-# the same 8Kb page, so that break.S can be more efficient when performing
-# single-step bypass management
+# (1) The trap table for debug mode
+# (2) The trap table for kernel mode
+# (3) The trap table for user mode
+#
+# The CPU jumps to an appropriate slot in the appropriate table to perform
+# exception processing. We have three different tables for the three
+# different CPU modes because there is no hardware differentiation between
+# stack pointers for these three modes, and so we have to invent one when
+# crossing mode boundaries.
+#
+# (4) The exception handler vector table
+#
+# The user and kernel trap tables use the same prologue for normal
+# exception processing. The prologue then jumps to the handler in this
+# table, as indexed by the exception ID from the TBR.
+#
+# (5) The fixup table for kernel-trap single-step
+# (6) The fixup table for user-trap single-step
+#
+# Due to the way single-stepping works on this CPU (single-step is not
+# disabled when crossing exception boundaries, only when in debug mode),
+# we have to catch the single-step event in break.S and jump to the fixup
+# routine pointed to by this table.
+#
+# The linker script places the user mode and kernel mode trap tables on to
+# the same 8Kb page, so that break.S can be more efficient when performing
+# single-step bypass management
#
###############################################################################
reply other threads:[~2004-12-14 16:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=9801.1103042059@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/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
Powered by JetHome