Bug 133799 - On s390[x] PTRACE_SINGLESTEP to deliver signal runs handler without single-step
Summary: On s390[x] PTRACE_SINGLESTEP to deliver signal runs handler without single-step
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: s390x
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 116894 117972 127692 132991
TreeView+ depends on / blocked
 
Reported: 2004-09-27 16:20 UTC by Andrew Cagney
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 19:17:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Deliver SIGTRAP for first instruction of a single stepped signal handler. (1.53 KB, patch)
2004-11-29 16:13 UTC, Martin Schwidefsky
no flags Details | Diff

Description Andrew Cagney 2004-09-27 16:20:22 UTC
Description of problem lifted from 130995; I used devel5 to test this.

The ptrace(PT_STEP,SIGALARM) system call instead implements
ptrace(PT_CONTINUE,SIGALARM).

Version-Release number of selected component (if applicable):

Roland says this is present in all i386 kernels.

How reproducible:

Always.

Steps to Reproduce:

In the below, target_resume(...) corresponds directly to a ptrace call.

cagney@tomago$ gdb ./a.out
[...]
(gdb) b handler
Breakpoint 1 at 0x80483bb: file sigstep.c, line 31.
(gdb) list main
39	  itimer_real = ITIMER_REAL,
40	  itimer_virtual = ITIMER_VIRTUAL
41	} itimer = ITIMER_REAL; /* ITIMER_VIRTUAL; */
42	
43	main ()
44	{
45	
46	  /* Set up the signal handler.  */
47	  memset (&action, 0, sizeof (action));
48	  action.sa_handler = handler;
(gdb) 
49	  sigaction (SIGVTALRM, &action, NULL);
50	  sigaction (SIGALRM, &action, NULL);
51	
52	  /* The values needed for the itimer.  This needs to be at least long
53	     enough for the setitimer() call to return.  */
54	  memset (&itime, 0, sizeof (itime));
55	  itime.it_value.tv_usec = 250 * 1000;
56	
57	  /* Loop for ever, constantly taking an interrupt.  */
58	  while (1)
(gdb) 
59	    {
60	      /* Set up a one-off timer.  A timer, rather than SIGSEGV, is
61		 used as after a timer handler finishes the interrupted code
62		 can safely resume.  */
63	      setitimer (itimer, &itime, NULL);
64	      /* Wait.  */
65	      while (!done);
66	      done = 0;
67	    }
68	}
(gdb) break 65
Breakpoint 2 at 0x8048456: file sigstep.c, line 65.
(gdb) set debug target 1
(gdb) run
Starting program: /home/cagney/tmp/sigstep/a.out 
[...]
Breakpoint 2, main () at sigstep.c:65
65	      while (!done);
(gdb) step
target_terminal_inferior ()
target_xfer_memory (0x8048456, xxx, 2, read, xxx) = 2, bytes = a1 64

Keeps re-delivering the signal.

The ptrace(PT_STEP,SIGNAL) should setup the signal and then execute no
instructions.

Comment 3 Martin Schwidefsky 2004-11-29 16:12:38 UTC
Uli fixed this for s390. If ptrace is called with PTRACE_SINGLESTEP
and with exit code > 0 the TIF_SINGLE_STEP bit is set instead of the
PER bit in the PSW. This makes entry.S to deliver a SIGTRAP with the
PSW pointing to the first instruction of the signal handler. See patch
below.

Comment 4 Martin Schwidefsky 2004-11-29 16:13:44 UTC
Created attachment 107546 [details]
Deliver SIGTRAP for first instruction of a single stepped signal handler.

Comment 5 Pete Zaitcev 2004-11-29 16:56:53 UTC
But this is a 2.4 based release...


Comment 7 RHEL Program Management 2007-10-19 19:17:30 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.


Note You need to log in before you can comment on or make changes to this bug.