Red Hat Bugzilla – Bug 126699
single-stepping over system call or trapping instruction executes two instructions instead of one on i386
Last modified: 2007-11-30 17:07:02 EST
Description of problem:
Version-Release number of selected component (if applicable):
All known kernels.
Steps to Reproduce:
1. Compiled attached stepi.c: gcc -o stepi -g -O99 stepi.c
2. Run attached gdb script on it: gdb -nx -x ./stepi.x ./stepi
3. Check output for results of single-stepping `into' insn,
`int $0x80', and stepping through vsyscall kernel entry.
stepi at into/int $0x80/sysenter executes that insn plus the next one.
stepi should execute exactly one instruction and then stop again.
See bug 126089 for discussion that brought this issue up.
The same behavior is seen on x86-64 kernel with x86-64 gdb running
Created attachment 101385 [details]
C program used in test
This program demonstrates an into trap, and both flavors of system call.
Created attachment 101386 [details]
gdb script to reproduce the bug using the stepi.c test program
gcc -o stepi -g -O9 stepi.c
gdb -nx -x ./stepi.x ./stepi
Created attachment 101387 [details]
output from gdb -x stepi.x stepi on unfixed kernel
This output is from gdb on an x86-64 kernel, but the output seen from an x86
kernel has exactly the same failures. Note stepping at 0x804844b next stops at
0x8048451 rather than 0x0804844c; at 0x0804845b stops at 0x8048462 instead of
0x0804845d; at 0xffffe405 stops at 0xffffe411 rather than 0xffffe410.
Created attachment 101388 [details]
output from gdb -x stepi.x stepi on a fixed x86 kernel
This output is running on an i686 kernel that is vanilla 2.6-current plus a
patch from me. Note all the correct stepping in contrast to the previous
Related bugs are #126908 (ppc64), #126911 (x86_64), and #126913 (ia64).
Verified that assignees of those bugs are on the cc: list for this one.
Created attachment 101496 [details]
patch for upstream 2.6 kernel i386 code
Proposed upstream 2.6 kernel patch to fix this for x86.
I've just posted this to the linux-kernel mailing list.
Note that x86-64 emulating x86 has the same issue and needs its own patch.
There is a different patch with the same effect in the 2.6.7-mm kernel
series. Our kernel team can pursue encouraging Linus to take this
patch into the maintstream kernel, and/or decide to use it in FC/RHEL
Created attachment 101844 [details]
patch for upstream x86_64 kernel ia32 support
This is the patch I have submitted upstream to bring x86_64's support for
ptrace'ing 32-bit processes in line with the native 32-bit ptrace behavior
achieved in the aforementioned i386 patch.
Created attachment 102830 [details]
patch for 2.4.21-18.EL
The 2.6 version of the fix for this for both x86 and x86-64 (both native and
32-bit support) is in the -mm kernel and I have upstream agreement from Linus
that it should go into 2.6.9.
I have done a backport to the RHEL3 kernel, attached here is a patch relative
to the 2.4.21-18.EL kernel sources. Andrew and I have tested this on x86.
I've tested it on x86-64 as well but have not gotten confirmation from Andrew.
submitted the patch.
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-20.8.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.