Fix gdb.trace/actions.exp race

I saw this on PPC64 once:

  not installed on target
  (gdb) PASS: gdb.trace/actions.exp: 5.10a: verify teval actions set for two tracepoints
  break main
  Breakpoint 4 at 0x10000c6c: file ../../../src/gdb/testsuite/gdb.trace/actions.c, line 139.
  (gdb) PASS: gdb.trace/actions.exp: break main
  run
  Starting program: /home/palves/gdb/build/gdb/testsuite/outputs/gdb.trace/actions/actions
  tstatus

  Breakpoint 4, main (argc=1, argv=0x3fffffffebb8, envp=0x3fffffffebc8) at ../../../src/gdb/testsuite/gdb.trace/actions.c:139
  139       begin ();
  (gdb) tstatus
  Trace can not be run on this target.
  (gdb) actions 1
  Enter actions for tracepoint 1, one per line.
  End with a line saying just "end".
  >collect $regs
  >end
  (gdb) PASS: gdb.trace/actions.exp: set actions for first tracepoint
  tstart
  You can't do that when your target is `native'
  (gdb) FAIL: gdb.trace/actions.exp: tstart
  info tracepoints 1
  Num     Type           Disp Enb Address            What
  1       tracepoint     keep y   0x00000000100007c8 in gdb_c_test at ../../../src/gdb/testsuite/gdb.trace/actions.c:74
	  collect $regs
	  not installed on target
  ...

followed by a cascade of FAILs.  The "tstatus" was supposed to detect
that this target (native) can't do tracepoints, but, alas, it didn't.

That detection failed because 'gdb_test "break main"' doesn't expect
anything, and then the output was slow enough that 'gdb_test ""
"Breakpoint .*"' matched the output of "break main"...

The fix is to use gdb_breakpoint instead.  Also check the result of
gdb_test while at it.

Tested on x86-64 Fedora 20, native and gdbserver.

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

	* gdb.trace/actions.exp: Use gdb_breakpoint instead of gdb_test
	that doesn't expect anything.  Return early if running to main
	fails.

0 files changed, 0 insertions, 0 deletions