This is the mail archive of the gdb-cvs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb and binutils branch master updated. 829155c9adb5f3750c9c612702fdbf26fa7c558e


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  829155c9adb5f3750c9c612702fdbf26fa7c558e (commit)
      from  61c8d22ea32f86034340778f29c7fd9aaf144052 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=829155c9adb5f3750c9c612702fdbf26fa7c558e

commit 829155c9adb5f3750c9c612702fdbf26fa7c558e
Author: Pedro Alves <palves@redhat.com>
Date:   Fri Jun 6 19:59:21 2014 +0100

    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.

-----------------------------------------------------------------------

Summary of changes:
 gdb/testsuite/ChangeLog                        |    7 +++++
 gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp |   31 ++++++++++-------------
 2 files changed, 21 insertions(+), 17 deletions(-)


hooks/post-receive
-- 
gdb and binutils


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]