diff options
| author | Pedro Alves <palves@redhat.com> | 2015-04-08 10:39:43 +0100 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2015-04-08 10:39:43 +0100 |
| commit | 4496bed7f346afbb2f2b4f939373920a4d69da11 (patch) | |
| tree | 461a57b0386cd2c11690ab92e59ef71d0629c7e6 /gdb/testsuite/gdb.trace/infotrace.exp | |
| parent | 2449132744a7081d1c8619da45cc9870d9c98fb3 (diff) | |
| download | gdb-4496bed7f346afbb2f2b4f939373920a4d69da11.zip gdb-4496bed7f346afbb2f2b4f939373920a4d69da11.tar.gz gdb-4496bed7f346afbb2f2b4f939373920a4d69da11.tar.bz2 | |
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.
Diffstat (limited to 'gdb/testsuite/gdb.trace/infotrace.exp')
| -rw-r--r-- | gdb/testsuite/gdb.trace/infotrace.exp | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/gdb/testsuite/gdb.trace/infotrace.exp b/gdb/testsuite/gdb.trace/infotrace.exp index 4e96ea2..3b861ea 100644 --- a/gdb/testsuite/gdb.trace/infotrace.exp +++ b/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" |