This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/16062] New: stepi sometimes doesn't make progress
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 18 Oct 2013 14:16:57 +0000
- Subject: [Bug gdb/16062] New: stepi sometimes doesn't make progress
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16062
Bug ID: 16062
Summary: stepi sometimes doesn't make progress
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: palves at redhat dot com
I noticed something odd while doing "stepi" over a fork syscall:
...
(gdb) set disassemble-next-line on
...
(gdb) si
0x000000323d4ba7c2 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00
mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea
0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov
$0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov
$0x38,%eax
=> 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp
$0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja
0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00
mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea
0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov
$0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov
$0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp
$0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja
0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00
mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea
0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov
$0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov
$0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp
$0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja
0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7ca 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00
mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea
0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov
$0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov
$0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp
$0xfffffffffffff000,%rax
=> 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja
0x323d4ba8fb <__libc_fork+475>
Notice how the third "si" didn't actually make progress.
--
You are receiving this mail because:
You are on the CC list for the bug.