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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.