c708f4d256
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"
This commit also adds a check to gdb_load_shlib that GDB is running.
The check is always performed, so this should catch cases where a GDB
developer adds a use of gdb_load_shlib but doesn't test their code
with a remote target.
gdb/testsuite/ChangeLog:
* gdb.trace/tspeed.exp: Only call gdb_load_shlib after gdb has
started.
* lib/gdb.exp (gdb_load_shlib): Call perror if GDB is not running.
|
||
|---|---|---|
| .. | ||
| ada.exp | ||
| append_gdb_boards_dir.exp | ||
| build-piece.exp | ||
| cache.exp | ||
| cell.exp | ||
| cl_util.c | ||
| cl_util.h | ||
| compiler.c | ||
| compiler.cc | ||
| completion-support.exp | ||
| cp-support.exp | ||
| d-support.exp | ||
| data-structures.exp | ||
| dtrace.exp | ||
| dwarf.exp | ||
| fortran.exp | ||
| future.exp | ||
| gdb-guile.exp | ||
| gdb-python.exp | ||
| gdb-utils.exp | ||
| gdb.exp | ||
| gdbserver-support.exp | ||
| gen-perf-test.exp | ||
| go.exp | ||
| memory.exp | ||
| mi-support.exp | ||
| objc.exp | ||
| opencl_hostapp.c | ||
| opencl_kernel.cl | ||
| opencl.exp | ||
| pascal.exp | ||
| pdtrace.in | ||
| perftest.exp | ||
| prelink-support.exp | ||
| prompt.exp | ||
| range-stepping-support.exp | ||
| read1.c | ||
| rust-support.exp | ||
| selftest-support.exp | ||
| set_unbuffered_mode.c | ||
| trace-support.exp | ||
| unbuffer_output.c | ||