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. How reproducible: 100% 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. Actual results: stepi at into/int $0x80/sysenter executes that insn plus the next one. Expected results: stepi should execute exactly one instruction and then stop again. Additional info: See bug 126089 for discussion that brought this issue up. The same behavior is seen on x86-64 kernel with x86-64 gdb running 32-bit binaries.
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 example.
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 kernels. http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.7/2.6.7-mm7/broken-out/really-ptrace-single-step-2.patch
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. http://rhn.redhat.com/errata/RHBA-2004-550.html