From: Corey Minyard <minyard@acm.org>
To: Corey Minyard <minyard@acm.org>
Cc: Matt Porter <mporter@kernel.crashing.org>,
linuxppc-dev@lists.linuxppc.org
Subject: Re: Change to allow signal handlers to set SE and BE bits.
Date: Fri, 05 Sep 2003 10:23:53 -0500 [thread overview]
Message-ID: <3F58AA89.80803@acm.org> (raw)
In-Reply-To: <3F574958.4090402@acm.org>
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
Here's an example patch (that I have tested) that shows the use of the
top 16 bits of the trap field as communication between the signal
handler and the kernel.
-Corey
Corey Minyard wrote:
>
> Actually, using the SE bit may not be the best way to handle this to
> cover all the PPC variants.
>
> Would it be better to have a special bit field someplace that is used to
> communicate between the signal handler and the kernel? Some
> possibilities are:
>
> * The top 16 bits of the trap field
> * The currently unused mq field (except on APUS?)
> * A new field in the signal frame
>
> I'm thinking that reserving the top 16 bits of the trap field may be the
> best. It would always come in as zero (so existing software won't be
> broken) and it will be available for all processors and will not be used
> for anything else by the processor.
>
> Any thoughts?
>
> -Corey
>
> Matt Porter wrote:
>
>> On Fri, Aug 29, 2003 at 03:00:51PM -0500, Corey Minyard wrote:
>>
>>
>>> I have a debugger that runs in an application that requires access to
>>> the SE and BE bits. The following patch adds that capability to
>>> 2.4.21-ben1. I have tested this, and gdb still seems to correctly step
>>> out of signal handlers, and it seems to work for 4xx. Does this
>>> look ok?
>>>
>>>
>>
[-- Attachment #2: ppc-dbgr2.diff --]
[-- Type: text/plain, Size: 2647 bytes --]
--- arch/ppc/kernel/signal.c.old 2003-08-28 15:30:37.000000000 -0500
+++ arch/ppc/kernel/signal.c 2003-09-05 09:17:49.000000000 -0500
@@ -304,6 +304,29 @@
GP_REGS_SIZE - PT_ORIG_R3 * sizeof(elf_greg_t)))
return 1;
+
+ /* Check any special handling requests from the signal
+ handler */
+ if (regs->trap >> 16) {
+ /* If the signal handler has asked for
+ single-stepping, set it up. */
+ if (regs->trap & PPC_TRAP_ENABLE_SINGLE_STEP) {
+#if defined(CONFIG_4xx)
+ regs->msr |= MSR_DE;
+ current->thread.dbcr0 |= (DBCR0_IDM | DBCR0_IC);
+#else
+ regs->msr |= MSR_SE;
+#endif
+ }
+ /* If the signal handler has asked for branch
+ tracing, set it up. */
+ if (regs->trap & PPC_TRAP_ENABLE_BRANCH_TRACE) {
+#if !defined(CONFIG_4xx)
+ regs->msr |= MSR_BE;
+#endif
+ }
+ }
+
/* force the process to reload the FP registers from
current->thread when it next does FP instructions */
regs->msr &= ~MSR_FP;
--- arch/ppc/kernel/traps.c.old 2003-08-28 15:42:26.000000000 -0500
+++ arch/ppc/kernel/traps.c 2003-09-05 09:15:47.000000000 -0500
@@ -396,7 +396,7 @@
void
SingleStepException(struct pt_regs *regs)
{
- regs->msr &= ~MSR_SE; /* Turn off 'trace' bit */
+ regs->msr &= ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
if (debugger_sstep(regs))
return;
_exception(SIGTRAP, regs, TRAP_TRACE, 0);
--- include/asm-ppc/ptrace.h.old 2003-09-05 09:02:15.000000000 -0500
+++ include/asm-ppc/ptrace.h 2003-09-05 09:16:43.000000000 -0500
@@ -29,11 +29,28 @@
unsigned long ccr;
unsigned long mq; /* 601 only (not used at present) */
/* Used on APUS to hold IPL value. */
+
+ /* Note that the high-order 16-bits of the trap field are used
+ to communicate information back from the signal handler, as
+ described in the PPC_TRAP_xxx macros below. You should
+ leave this alone if you do not need these functions. */
unsigned long trap; /* Reason for being here */
unsigned long dar; /* Fault registers */
unsigned long dsisr; /* used for ESR on 4xx/Book-E */
unsigned long result; /* Result of a system call */
};
+
+/* If you set this bit in the "trap" field when returning from a
+ signal handler, single stepping will be enabled on the first
+ instruction back from the signal handler, if the processor supports
+ this. */
+#define PPC_TRAP_ENABLE_SINGLE_STEP (1 << 16)
+
+/* If you set this bit in the "trap" field when returning from a
+ signal handler, branch tracing will be enabled on the first
+ instruction back from the signal handler, if the processor supports
+ this. */
+#define PPC_TRAP_ENABLE_BRANCH_TRACE (1 << 17)
#endif
#ifdef __KERNEL__
next prev parent reply other threads:[~2003-09-05 15:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-29 20:00 Change to allow signal handlers to set SE and BE bits Corey Minyard
2003-08-29 20:18 ` Matt Porter
2003-09-04 14:16 ` Corey Minyard
2003-09-05 15:23 ` Corey Minyard [this message]
2003-09-09 19:19 ` Corey Minyard
2003-09-09 19:39 ` Benjamin Herrenschmidt
2003-09-09 21:34 ` Corey Minyard
2003-09-10 1:37 ` Paul Mackerras
2003-09-10 2:47 ` Corey Minyard
2003-08-30 0:29 ` Paul Mackerras
2003-09-01 20:46 ` Corey Minyard
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=3F58AA89.80803@acm.org \
--to=minyard@acm.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mporter@kernel.crashing.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;
as well as URLs for NNTP newsgroup(s).