Description of problem lifted from 130995; I used devel5 to test this.
The ptrace(PT_STEP,SIGALARM) system call instead implements
Version-Release number of selected component (if applicable):
Roland says this is present in all i386 kernels.
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; */
43 main ()
46 /* Set up the signal handler. */
47 memset (&action, 0, sizeof (action));
48 action.sa_handler = handler;
49 sigaction (SIGVTALRM, &action, NULL);
50 sigaction (SIGALRM, &action, NULL);
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;
57 /* Loop for ever, constantly taking an interrupt. */
58 while (1)
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;
(gdb) break 65
Breakpoint 2 at 0x8048456: file sigstep.c, line 65.
(gdb) set debug target 1
Starting program: /home/cagney/tmp/sigstep/a.out
Breakpoint 2, main () at sigstep.c:65
65 while (!done);
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
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
Created attachment 107546 [details]
Deliver SIGTRAP for first instruction of a single stepped signal handler.
But this is a 2.4 based release...
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:
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.