This is the mail archive of the
gdb-cvs@sourceware.org
mailing list for the GDB project.
gdb and binutils branch master updated. 5b80f00d51b4eb40cb142a633bd657b84aca33eb
- From: palves at sourceware dot org
- To: gdb-cvs at sourceware dot org
- Date: 2 May 2014 00:00:05 -0000
- Subject: gdb and binutils branch master updated. 5b80f00d51b4eb40cb142a633bd657b84aca33eb
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