gdb and binutils branch master updated. d708bcd102465e520c56e8be3ca4c9097dd389cc

[palves@sourceware.org]

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  d708bcd102465e520c56e8be3ca4c9097dd389cc (commit)
      from  e4ef1b6c3fee295ab41138bf77a82dff16f1d7c3 (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=d708bcd102465e520c56e8be3ca4c9097dd389cc

commit d708bcd102465e520c56e8be3ca4c9097dd389cc
Author: Pedro Alves <palves@redhat.com>
Date:   Thu Apr 10 19:22:23 2014 +0100

    Conditional Z1 breakpoint hangs GDBserver.
    
    While trying to fix hbreak2.exp against GDBserver I noticed this...
    
     (gdb) hbreak main if 1
     Sending packet: $m400580,40#2e...Packet received: e8d2ffffff5dc3554889e54883ec10c745fc00000000eb0eb800000000e8c1ffffff8345fc01817dfce70300007ee9b800000000c9c3662e0f1f840000000000
     Sending packet: $m40058f,1#31...Packet received: c7
     Hardware assisted breakpoint 1 at 0x40058f: file ../../../src/gdb/testsuite/gdb.base/break-idempotent.c, line 46.
     Sending packet: $Z1,40058f,1;X3,220127#9b...
     *hangs forever*
    
    The issue is that nothing advances the packet pointer if
    add_breakpoint_condition either fails to parse the agent expression,
    or fails to find the breakpoint, resulting in an infinite loop in
    process_point_options.  The latter case should really be fixed by
    GDBserver tracking GDB Z1 breakpoints in its breakpoint structures
    like Z0 breakpoints are, but the latter case still needs handling.
    add_breakpoint_commands has the same issue, though at present I don't
    know any way to trigger it other than sending a manually cooked
    packet.
    
    Unbelievably, it doesn't look like we have any test that tries setting
    a conditional hardware breakpoint.  Looking at cond-eval-mode.exp, it
    looks like the file was meant to actually test something, but it's
    mostly empty today.  This patch adds tests that tries all sorts of
    conditional breakpoints and watchpoints.  The test hangs/fails without
    the GDBserver fix.
    
    Tested on x86_64 Fedora 17.
    
    gdb/gdbserver/
    2014-04-10  Pedro Alves  <palves@redhat.com>
    
    	* mem-break.c (add_breakpoint_condition, add_breakpoint_commands):
    	Check if the condition or command is NULL before checking if the
    	breakpoint is known.  On success, return true.
    	* mem-break.h (add_breakpoint_condition): Document return.
    	(add_breakpoint_commands): Add describing comment.
    	* server.c (skip_to_semicolon): New function.
    	(process_point_options): Use it.
    
    gdb/testsuite/
    2014-04-10  Pedro Alves  <palves@redhat.com>
    
    	* gdb.base/cond-eval-mode.c: New file.
    	* gdb.base/cond-eval-mode.exp: Use standard_testfile.  Adjust
    	prepare_for_testing to build the new file.  Check result of
    	runto_main.
    	(test_break, test_watch): New procedures.
    	(top level): Use them.

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

Summary of changes:
 gdb/gdbserver/ChangeLog                            |   10 ++
 gdb/gdbserver/mem-break.c                          |   16 ++--
 gdb/gdbserver/mem-break.h                          |    9 ++-
 gdb/gdbserver/server.c                             |   18 +++-
 gdb/testsuite/ChangeLog                            |    9 ++
 .../{source-execution.c => cond-eval-mode.c}       |   32 ++++--
 gdb/testsuite/gdb.base/cond-eval-mode.exp          |  112 +++++++++++++++++++-
 7 files changed, 181 insertions(+), 25 deletions(-)
 copy gdb/testsuite/gdb.base/{source-execution.c => cond-eval-mode.c} (79%)


hooks/post-receive
-- 
gdb and binutils