gdb and binutils branch master updated. 5b80f00d51b4eb40cb142a633bd657b84aca33eb

[palves at sourceware dot 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  5b80f00d51b4eb40cb142a633bd657b84aca33eb (commit)
      from  b46fa76826669b1496cac329d132485ede779d85 (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=5b80f00d51b4eb40cb142a633bd657b84aca33eb

commit 5b80f00d51b4eb40cb142a633bd657b84aca33eb
Author: Pedro Alves <palves@redhat.com>
Date:   Fri May 2 00:59:31 2014 +0100

    gdb_load: Fix latent bugs
    
    In a test I was writting, I needed a procedure that would connect to
    the target, and do "load", or equivalent.
    
    Years ago, boards would override gdb_load to implement that.  Then
    gdb_reload was added, and gdb_load was relaxed to allow boards avoid
    the spawing and connecting to the target.  This sped up gdbserver
    testing.  See
    https://www.sourceware.org/ml/gdb-patches/2007-02/msg00318.html.
    
    To actually spawn the target and load the executable on the target
    side, gdb_reload was born:
    
     # gdb_reload -- load a file into the target.  Called before "running",
     # either the first time or after already starting the program once,
     # for remote targets.  Most files that override gdb_load should now
     # override this instead.
    
     proc gdb_reload { } {
         # For the benefit of existing configurations, default to gdb_load.
         # Specifying no file defaults to the executable currently being
         # debugged.
         return [gdb_load ""]
     }
    
    Note the comment about specifying no file.  Indeed looking at
    config/sid.exp, or config/monitor.exp, we see examples of that.
    
    However, the default gdb_load itself doesn't handle the case of no
    file specified.  When passed no file, it just calls gdb_file_cmd with
    no file either, which ends up invocing the "file" command with no
    argument, which means unloading the file and its symbols...  That
    means calling gdb_reload when testing against native targets is
    broken.  We don't see that today because the only call to gdb_reload
    that exists today is guarded by target_info exists
    gdb,do_reload_on_run.
    
    The native-extended-gdbserver.exp board is likewise broken here.  When
    [gdb_load ""] is called, the board sets the remote exec-file to "" ...
    
    Tested on x86_64 Fedora 17, native, remote gdbserver and
    extended-remote gdbserver.
    
    testsuite/
    2014-05-01  Pedro Alves  <palves@redhat.com>
    
    	* lib/gdb.exp (gdb_load): Extend comment.  Skip calling
    	gdb_file_cmd if no file is specified.
    	* boards/native-extended-gdbserver.exp (gdb_load): Use the
    	last_loaded_file to set the remote exec-file.

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

Summary of changes:
 gdb/testsuite/ChangeLog                            |    7 +++++++
 gdb/testsuite/boards/native-extended-gdbserver.exp |    3 ++-
 gdb/testsuite/lib/gdb.exp                          |    7 +++++--
 3 files changed, 14 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
gdb and binutils