From: Matt Porter <mporter@kernel.crashing.org> Date: 2003-08-29 20:18:25
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?
Please change MSR_SE->MSR_DWE in the 4xx-specific sections. Also,
a comment should be added to each generic section use of MSR_SE to
make it clear that this is the BookE/4xx MSR_DWE.
-Matt
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
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:
quoted
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?
Please change MSR_SE->MSR_DWE in the 4xx-specific sections. Also,
a comment should be added to each generic section use of MSR_SE to
make it clear that this is the BookE/4xx MSR_DWE.
-Matt
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:
quoted
On Fri, Aug 29, 2003 at 03:00:51PM -0500, Corey Minyard wrote:
quoted
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?
Paul came up with a much better method for this. I have added a syscall
that does a "debug" return from the signal handler. It's much cleaner.
I ahve a patch for this, and I've done a number of things besides just
this. I seemed bad to me to add yet another kludge to the beginning of
DoSyscall for handling yet another signal return value. So I turned all
the signal return syscalls into normal syscalls. This should speed up
normal syscall handling by removing four instructions from the syscall
entry. Is this ok?
I added some new syscalls for each sigreturn option, but there were
already some more that would obviously not work for this. Should I
convert the others over to work correctly, or should I leave these like
they are?
I made the interface to the debug sigreturn extensible, it takes an
array of two-member structures, where the first member is a debug type
and the second is a debug value. This should allow a lot of flexibility
for adding new things (probably a lot more than is required).
I also brought the syscall table in asm/unistd.h up to date.
I've got some code for setting dabr from userland and causing traps. I
could work it into this if someone is interested. It involves some
complicated code at exception entry.
-Corey
Corey Minyard wrote:
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:
quoted
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
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2003-09-09 19:39:31
On Tue, 2003-09-09 at 21:19, Corey Minyard wrote:
Paul came up with a much better method for this. I have added a syscall
that does a "debug" return from the signal handler. It's much cleaner.
I ahve a patch for this, and I've done a number of things besides just
this. I seemed bad to me to add yet another kludge to the beginning of
DoSyscall for handling yet another signal return value. So I turned all
the signal return syscalls into normal syscalls. This should speed up
normal syscall handling by removing four instructions from the syscall
entry. Is this ok?
The problem with changing the signal return is that you break at least
gdb, and maybe more (g++ stack unwinding ?)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
What if you went back to using the original syscall numbers? Those seem
to have code in gdb to support them.
-Corey
Benjamin Herrenschmidt wrote:
On Tue, 2003-09-09 at 21:19, Corey Minyard wrote:
quoted
Paul came up with a much better method for this. I have added a syscall
that does a "debug" return from the signal handler. It's much cleaner.
I ahve a patch for this, and I've done a number of things besides just
this. I seemed bad to me to add yet another kludge to the beginning of
DoSyscall for handling yet another signal return value. So I turned all
the signal return syscalls into normal syscalls. This should speed up
normal syscall handling by removing four instructions from the syscall
entry. Is this ok?
The problem with changing the signal return is that you break at least
gdb, and maybe more (g++ stack unwinding ?)
Ben.
From: Paul Mackerras <hidden> Date: 2003-09-10 01:37:01
Corey Minyard writes:
I added some new syscalls for each sigreturn option, but there were
already some more that would obviously not work for this. Should I
convert the others over to work correctly, or should I leave these like
they are?
There already were numbers assigned for the sigreturn and rt_sigreturn
system calls which weren't being used in 2.4. In 2.5/2.6 I have
changed the kernel to use them. I thought the stack unwinding code in
glibc (at least) had already been updated to reflect that.
Which tree is your patch against? Note that there are PPC signal
changes in 2.4.23-pre3. I hope your patch is against the new version
not the old version. :)
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
After your and Ben's comments, I looked at this some more. Yes, I
should have used the old versions of sigreturn and rt_sigreturn. I have
looked at gdb and gcc unwinding. gdb 5.3 only handles the "7777"
(non-rt) signal frames properly. It does not handle rt frames. gdb 6.0
pre has handling code for the "6666" (rt), "7777" (non-rt), sigreturn,
and rt_sigreturn versions of the stack frames. However, the rt versions
are broken, it doesn't account for the different frame format in rt
signal handlers.
gcc unwinding looks ok, it handles the old and new versions of the stack
frame system calls.
I'm being a little persistent on this because I think changing the way
signal handling works would be better if changed. System calls would be
a little faster with the change (although signal returns would be
slightly slower, but I assume the occur less often). Plus, strace is
unable to trace signal returns with the way it works now. I consider
signal returns a pretty important thing for strace to show, and other
arches do this.
I've attached yet another patch. By default, this patch uses the
"0x6666" and "0x7777" versions of the signal return syscalls. The
DoSyscall code will translate from the 0x6666 and 0x7777 to the
sys_rt_sigreturn and sys_sigreturn. You can do "echo '0' >
/proc/sys/ppc/sigtype" to change it to use the syscalls for
sys_sigreturn and sys_rt_sigreturn. I've tested gdb 5.3, gdb 6.0, and
strace with it in both modes. (when using sys_sigreturn, strace
actually prints the right thing).
I'm going to test signal unwinding now after I brush up on my C++ skills
:-). I expect they will work, but I'll send an email.
This is against 2.4.22-ben2, and it has the new code. The 2.5 code is
quite different, but my changes make 2.4 more like 2.5. A 2.5 patch
would be pretty easy to do.
I also have a patch against 2.4.20 (I have to do that version for our
product), but with stacked signal frames things get ugly.
-Corey
Paul Mackerras wrote:
Corey Minyard writes:
quoted
I added some new syscalls for each sigreturn option, but there were
already some more that would obviously not work for this. Should I
convert the others over to work correctly, or should I leave these like
they are?
There already were numbers assigned for the sigreturn and rt_sigreturn
system calls which weren't being used in 2.4. In 2.5/2.6 I have
changed the kernel to use them. I thought the stack unwinding code in
glibc (at least) had already been updated to reflect that.
Which tree is your patch against? Note that there are PPC signal
changes in 2.4.23-pre3. I hope your patch is against the new version
not the old version. :)
Paul.