Bug 133782
Summary: | On PowerPC PTRACE_SINGLESTEP to deliver signal runs handler without single-step | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Andrew Cagney <cagney> |
Component: | kernel | Assignee: | David Woodhouse <dwmw2> |
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | dwmw2, jlaska, peterm, petrides, riel, roland |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | powerpc | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-12-20 20:56:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 116894, 117972, 127692 |
Description
Andrew Cagney
2004-09-27 13:08:45 UTC
Thanks, David. Andrew, could you please verify that this bug has been fixed by testing on p630.lab.boston.redhat.com (or installing a kernel from porkchop as described in comment #6)? In 32-bit mode, the PT_STEP, it's issuing one instruction after constructing the signal frame. It should just construct the signal frame, adjust the PC to signal-handler address and then fake a sigtrap. See the corresponding i386 PR for the background. (gdb) b 65 Breakpoint 1 at 0x10000550: file sigstep.c, line 65. (gdb) run Starting program: /tmp/cagney/sigstep Breakpoint 1, main () at sigstep.c:65 65 while (!done); (gdb) break *handler Breakpoint 2 at 0x10000480: file sigstep.c, line 30. (gdb) stepi 0x10000554 65 while (!done); in detail: (gdb) stepi target_xfer_memory (0x100004ac, xxx, 4, read, xxx) = 4, bytes = 94 21 ff e0 target_xfer_memory (0x100004b0, xxx, 4, read, xxx) = 4, bytes = 7c 08 02 a6 target_xfer_memory (0x100004b4, xxx, 4, read, xxx) = 4, bytes = 93 e1 00 1c target_xfer_memory (0x100004b8, xxx, 4, read, xxx) = 4, bytes = 90 01 00 24 target_xfer_memory (0x100004bc, xxx, 4, read, xxx) = 4, bytes = 7c 3f 0b 78 target_xfer_memory (0x100004c0, xxx, 4, read, xxx) = 4, bytes = 3d 20 10 01 target_fetch_registers (r1) = ffffdbe0 0xffffdbe0 4294958048 target_xfer_memory (0xffffdbe0, xxx, 4, read, xxx) = 4, bytes = ff ff dc 00 target_fetch_registers (r31) = ffffdbe0 0xffffdbe0 4294958048 target_terminal_inferior () target_resume (10456, step, 0) target_wait (-1, status) = 10456, status->kind = stopped, signal = SIGALRM target_fetch_registers (pc) = 10000550 0x10000550 268436816 target_xfer_memory (0x10000550, xxx, 4, read, xxx) = 4, bytes = 3d 20 10 01 target_xfer_memory (0x1000054c, xxx, 4, read, xxx) = 4, bytes = 48 01 05 55 target_xfer_memory (0x10000550, xxx, 4, read, xxx) = 4, bytes = 3d 20 10 01 target_xfer_memory (0x1000054c, xxx, 4, read, xxx) = 4, bytes = 48 01 05 55 target_xfer_memory (0x100004ac, xxx, 4, read, xxx) = 4, bytes = 94 21 ff e0 target_xfer_memory (0x100004b0, xxx, 4, read, xxx) = 4, bytes = 7c 08 02 a6 target_xfer_memory (0x100004b4, xxx, 4, read, xxx) = 4, bytes = 93 e1 00 1c target_xfer_memory (0x100004b8, xxx, 4, read, xxx) = 4, bytes = 90 01 00 24 target_xfer_memory (0x100004bc, xxx, 4, read, xxx) = 4, bytes = 7c 3f 0b 78 target_xfer_memory (0x100004c0, xxx, 4, read, xxx) = 4, bytes = 3d 20 10 01 target_fetch_registers (r1) = ffffdbe0 0xffffdbe0 4294958048 target_xfer_memory (0xffffdbe0, xxx, 4, read, xxx) = 4, bytes = ff ff dc 00 target_fetch_registers (r31) = ffffdbe0 0xffffdbe0 4294958048 target_terminal_inferior () target_resume (10456, step, SIGALRM) target_wait (-1, status) = 10456, status->kind = stopped, signal = SIGTRAP target_fetch_registers (pc) = 10000484 0x10000484 268436612 Notice how the resume/step/sigalarm stopped at 0x10000484 and not 0x10000480. I think 64-bit PPC has the same problem. The patch in comment #12 has just been committed to the RHEL3 U4 patch pool this evening (in kernel version 2.4.21-23.EL). The additional siginfo problem will be fixed in U5. ernie: it sounds as if there are 2 issues gathered in this one bug. Would it make sense to move the siginfo problem into a seperate bug targetted for a RHEL3-U5 Blocker list? James, that's probably a good idea. James/Andrew/David, is there a new bugzilla for the ppc64 siginfo problems? Not AFAIK; Paulus fixed them before Andrew had a chance to track them down and make a properly coherent report. The original bug is fixed; The second bug isn't but that should really be filed separately. This bug report is considered fully resolved in U4 and will be closed when the U4 advisory is pushed on RHN. I'm removing it from the U5 blocker list. The ppc64 siginfo rework was committed to 2.4.21-24.EL. An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-550.html |