Fix gdb.trace/{actions,infotrace,while-stepping}.exp with extended-remote

The recent actions.exp change to check gdb_run_cmd succeeded caught
further problems.  The test now fails like this
with --target_board=native-extended-gdbserver:

 FAIL: gdb.trace/actions.exp: Can't run to main

gdb.log shows:

 (gdb) run
 Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.trace/actions
 Running the default executable on the remote target failed; try "set remote exec-file"?
 (gdb) FAIL: gdb.trace/actions.exp: Can't run to main

The problem is that a gdb_load call is missing.

Grepping around for similar problems in other tests, I found that
infotrace.exp and while-stepping.exp should be likewise affected.  And
indeed this is what we get today:

 FAIL: gdb.trace/infotrace.exp: tstart
 FAIL: gdb.trace/infotrace.exp: continue to end (the program is no longer running)
 FAIL: gdb.trace/infotrace.exp: tstop
 FAIL: gdb.trace/infotrace.exp: 2.6: info tracepoints (trace buffer usage)
 FAIL: gdb.trace/while-stepping.exp: tstart
 FAIL: gdb.trace/while-stepping.exp: tstop
 FAIL: gdb.trace/while-stepping.exp: tfile: info tracepoints
 FAIL: gdb.trace/while-stepping.exp: ctf: info tracepoints

while-stepping.exp even has the same race bug actions.exp had.

After this, {actions,infotrace,while-stepping}.exp all pass cleanly
with the native-extended-gdbserver board.

gdb/testsuite/ChangeLog:
2015-04-08  Pedro Alves  <palves@redhat.com>

	* gdb.trace/actions.exp: Use gdb_load before gdb_run_cmd.
	* gdb.trace/infotrace.exp: Use gdb_load before gdb_run_cmd.  Use
	gdb_breakpoint instead of gdb_test that doesn't expect anything.
	Return early if running to main fails.
	* gdb.trace/while-stepping.exp: Likewise.

0 files changed, 0 insertions, 0 deletions