aboutsummaryrefslogtreecommitdiff
path: root/gdb/guile/scm-utils.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-06-06 19:59:21 +0100
committerPedro Alves <palves@redhat.com>2014-06-06 19:59:21 +0100
commit829155c9adb5f3750c9c612702fdbf26fa7c558e (patch)
tree80210a52d20d6c7b0ec137e44cdef56689cc8692 /gdb/guile/scm-utils.c
parent61c8d22ea32f86034340778f29c7fd9aaf144052 (diff)
downloadbinutils-829155c9adb5f3750c9c612702fdbf26fa7c558e.zip
binutils-829155c9adb5f3750c9c612702fdbf26fa7c558e.tar.gz
binutils-829155c9adb5f3750c9c612702fdbf26fa7c558e.tar.bz2
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I sometimes still see an int3 in the disassembly: (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0 disassemble test Dump of assembler code for function test: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: mov %rsp,%rbp 0x0000000000400594 <+4>: nop => 0x0000000000400595 <+5>: int3 0x0000000000400596 <+6>: pop %rbp 0x0000000000400597 <+7>: retq End of assembler dump. (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches Enabling infrun/target debug logs, we can see the problem. Simplified, that's: (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break stepi_del_break infrun: clear_proceed_status_thread (process 25311) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594 LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread) target_resume (25311, step, 0) native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG] 0x400595 is the address of the breakpoint, and "= 0" is TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to remove the breakpoint, but failing. The problem is that we had just resumed the target and the native GNU/Linux target can't read memory off of a running thread. Most of the time, we get "lucky", because we manage to read memory before the kernel actually schedules the target to run. So just give up and skip the test on any target that uses hardware stepping, not just remote targets. gdb/testsuite/ 2014-06-06 Pedro Alves <palves@redhat.com> * gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step) in target debug output instead of looking at RSP packets, disabling the test on any target that uses hardware stepping. Update comments.
Diffstat (limited to 'gdb/guile/scm-utils.c')
0 files changed, 0 insertions, 0 deletions