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.

gdb/testsuite/ChangeLog

@@ -1,3 +1,11 @@
+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.
+
 2015-04-07  Pedro Alves  <palves@redhat.com>
 
 	* gdb.base/interrupt.exp: Don't skip if $inferior_spawn_id !=

gdb/testsuite/gdb.trace/actions.exp

@@ -235,6 +235,9 @@ gdb_test "info tracepoints" \
 \[\t \]+not installed on target." \
 		"5.10a: verify teval actions set for two tracepoints"
 
+# Load the binary to the target too.
+gdb_load $binfile
+
 # Can't use runto_main here, because that would delete the tracepoints
 # created above.
 gdb_breakpoint "main"

gdb/testsuite/gdb.trace/infotrace.exp

@@ -91,11 +91,20 @@ gdb_test "help info tracepoints" \
 
 # 2.6 info tracepoints (check trace buffer usage).  We need a live
 # tracing.
+
+# Load the binary to the target too.
+gdb_load $binfile
+
+# Can't use runto_main here, because that would delete the tracepoints
+# created above.
 gdb_breakpoint "main"
 gdb_trace_setactions "collect on tracepoint 1" "1" \
 	"collect gdb_struct1_test" "^$"
 gdb_run_cmd
-gdb_test "" "Breakpoint ${decimal}, main.*"
+if {[gdb_test "" "Breakpoint ${decimal}, main.*"] != 0} {
+    fail "Can't run to main"
+    return -1
+}
 
 if { ![gdb_target_supports_trace] } then {
     unsupported "Current target does not support trace"

gdb/testsuite/gdb.trace/while-stepping.exp

@@ -99,9 +99,19 @@ gdb_test "info tracepoints" \
 .*end.*" \
 	"5.16: confirm actions, step without collecting anything"
 
-gdb_test "break main"
+# Can't use runto_main here, because that would delete the tracepoints
+# created above.
+
+# Load the binary to the target too.
+gdb_load $binfile
+
+gdb_breakpoint "main"
 gdb_run_cmd
-gdb_test "" "Breakpoint .*"
+if {[gdb_test "" "Breakpoint .*"] != 0} {
+    fail "Can't run to main"
+    return -1
+}
+
 if ![gdb_target_supports_trace] {
     unsupported "target does not support trace"
     return -1