gdb: Don't call gdb_load_shlib unless GDB is running
Commit Message
The gdb_load_shlib function will, on remote targets, try to run some
GDB commands. This obviously isn't going to work unless GDB is
running.
The gdb.trace/tspeed.exp test calls gdb_load_shlib before starting
GDB. Don't do that.
The failure that's triggered is actually DeJaGNU complaining that the
variable $use_gdb_stub doesn't exist, this is only created when GDB is
started. Something like this should trigger a failure:
make check-gdb \
RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost \
gdb.trace/tspeed.exp"
gdb/testsuite/ChangeLog:
* gdb.trace/tspeed.exp: Only call gdb_load_shlib after gdb has
started.
---
gdb/testsuite/ChangeLog | 5 +++++
gdb/testsuite/gdb.trace/tspeed.exp | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
Comments
On 07/11/2018 10:06 AM, Andrew Burgess wrote:
> The gdb_load_shlib function will, on remote targets, try to run some
> GDB commands. This obviously isn't going to work unless GDB is
> running.
>
> The gdb.trace/tspeed.exp test calls gdb_load_shlib before starting
> GDB. Don't do that.
>
> The failure that's triggered is actually DeJaGNU complaining that the
> variable $use_gdb_stub doesn't exist, this is only created when GDB is
> started. Something like this should trigger a failure:
>
> make check-gdb \
> RUNTESTFLAGS="--target_board=remote-gdbserver-on-localhost \
> gdb.trace/tspeed.exp"
Wow, I never even noticed that -- good catch.
> diff --git a/gdb/testsuite/gdb.trace/tspeed.exp b/gdb/testsuite/gdb.trace/tspeed.exp
> index ecd36d2d9bd..47a82502a00 100644
> --- a/gdb/testsuite/gdb.trace/tspeed.exp
> +++ b/gdb/testsuite/gdb.trace/tspeed.exp
> @@ -126,6 +126,8 @@ proc gdb_trace_collection_test {} {
> }
>
> clean_restart $executable
> +gdb_load_shlib $ipalib
> +
> runto_main
>
> if { ![gdb_target_supports_trace] } then {
>
While I agree with the patch, I think more c/should be done to ensure that this scenario doesn't happen again. At the very least, mention this limitation in the procedure's comments.
However, is it possible/desirable to error if gdb hasn't been spawned ('![info exists ::gdb_spawn_id]' IIUC)? That should catch any other places where this currently happens (if any) and (more important) prevent this from happening in the future. [IANAM*]
Thanks,
Keith
* I am not a maintainer
@@ -19,7 +19,6 @@ standard_testfile
set executable $testfile
set ipalib [get_in_proc_agent]
-gdb_load_shlib $ipalib
if { [gdb_compile "$srcdir/$subdir/$srcfile" $binfile \
executable [concat {debug nowarnings c} shlib=$ipalib]] != "" } {
@@ -41,6 +40,7 @@ proc prepare_for_trace_test {} {
global executable
clean_restart $executable
+ gdb_load_shlib $ipalib
runto_main
@@ -126,6 +126,8 @@ proc gdb_trace_collection_test {} {
}
clean_restart $executable
+gdb_load_shlib $ipalib
+
runto_main
if { ![gdb_target_supports_trace] } then {