Bug 126699

Summary: single-stepping over system call or trapping instruction executes two instructions instead of one on i386
Product: Red Hat Enterprise Linux 3 Reporter: Roland McGrath <roland>
Component: kernelAssignee: Ingo Molnar <mingo>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 3.0CC: bjorn.helgaas, cagney, dhowells, jbaron, jparadis, petrides, riel
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-20 20:55:23 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: 126089    
Attachments:
Description Flags
C program used in test
none
gdb script to reproduce the bug using the stepi.c test program
none
output from gdb -x stepi.x stepi on unfixed kernel
none
output from gdb -x stepi.x stepi on a fixed x86 kernel
none
patch for upstream 2.6 kernel i386 code
none
patch for upstream x86_64 kernel ia32 support
none
patch for 2.4.21-18.EL none

Description Roland McGrath 2004-06-24 22:10:40 UTC
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.

Comment 1 Roland McGrath 2004-06-24 22:11:57 UTC
Created attachment 101385 [details]
C program used in test 

This program demonstrates an into trap, and both flavors of system call.

Comment 2 Roland McGrath 2004-06-24 22:13:12 UTC
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

Comment 3 Roland McGrath 2004-06-24 22:18:04 UTC
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.

Comment 4 Roland McGrath 2004-06-24 22:20:29 UTC
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.

Comment 5 Ernie Petrides 2004-06-29 00:30:05 UTC
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.


Comment 6 Roland McGrath 2004-06-29 01:56:57 UTC
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.

Comment 7 Roland McGrath 2004-07-12 20:55:02 UTC
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

Comment 8 Roland McGrath 2004-07-12 23:58:41 UTC
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.

Comment 12 Roland McGrath 2004-08-18 11:23:33 UTC
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.

Comment 13 Ingo Molnar 2004-08-21 08:15:58 UTC
submitted the patch.

Comment 15 Ernie Petrides 2004-09-20 06:44:53 UTC
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).


Comment 16 John Flanagan 2004-12-20 20:55:23 UTC
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