diff mbox

gdb: Don't call gdb_load_shlib unless GDB is running

Message ID 20180711170612.25873-1-andrew.burgess@embecosm.com
State New, archived
Headers

Commit Message

Andrew Burgess July 11, 2018, 5:06 p.m. UTC 
  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

Keith Seitz July 12, 2018, 4:11 p.m. UTC | #1 
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
diff mbox

Patch

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
@@ -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 {