This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
breakpoints/1702: System call executes two instructions
- From: ac131313 at redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 6 Jul 2004 14:46:41 -0000
- Subject: breakpoints/1702: System call executes two instructions
- Reply-to: ac131313 at redhat dot com
>Number: 1702
>Category: breakpoints
>Synopsis: System call executes two instructions
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jul 06 14:48:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: ac131313@redhat.com
>Release: 2004-06-07
>Organization:
>Environment:
Many kernels: Linux, IRIX, NetBSD, ...
>Description:
When single-stepping a system call, the kernel allows the inferior to execute not just the system-call instruction, but also the instruction following it.
In the below:
(gdb) c
Continuing.
...
Breakpoint 1, 0x080486bf in kill ()
1: x/i $pc 0x80486bf <kill+15>: int $0x80
(gdb) disassemble
Dump of assembler code for function kill:
0x080486b0 <kill+0>: mov %ebx,%edx
0x080486b2 <kill+2>: mov 0x8(%esp,1),%ecx
0x080486b6 <kill+6>: mov 0x4(%esp,1),%ebx
0x080486ba <kill+10>: mov $0x25,%eax
0x080486bf <kill+15>: int $0x80
0x080486c1 <kill+17>: mov %edx,%ebx
0x080486c3 <kill+19>: cmp $0xfffff001,%eax
0x080486c8 <kill+24>: jae 0x804e600 <__syscall_error>
0x080486ce <kill+30>: ret
0x080486cf <kill+31>: nop
End of assembler dump.
(gdb) stepi
0x080486c3 in kill ()
1: x/i $pc 0x80486c3 <kill+19>: cmp $0xfffff001,%eax
(gdb)
given the sequence:
0x080486bf <kill+15>: int $0x80
0x080486c1 <kill+17>: mov %edx,%ebx
0x080486c3 <kill+19>: cmp $0xfffff001,%eax
and the inferior stoped at "int $0x80", notice how the stepi skips the "mov %edx,%ebx" instruction stopping at "cmp $0xfff...".
For some kernels this happens with all system calls, for others it only happens with sigreturn.
The sigbpt.exp testcase tickles the sigreturn edge case - it checks that single-stepping out of a SIGSEGV signal handler can be halted at the faulting instruction (i.e., the sigsegv doesn't re-occure).
It is possible"fix" this (i.e., work around the kernel) by using software single step. Fixing the kernel is better though.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: