diff options
author | Simon Marchi <simon.marchi@polymtl.ca> | 2022-11-18 11:06:47 -0500 |
---|---|---|
committer | Simon Marchi <simon.marchi@polymtl.ca> | 2022-11-28 09:40:26 -0500 |
commit | 4a6bdfb9baa27e29151c7e97ae2abbe902f53638 (patch) | |
tree | ebd9a4dda63720552475abc0f25dba296ec07e6b /gprof/bbconv.pl | |
parent | 912b12ad84adf32af5827511af5afecedb108c63 (diff) | |
download | gdb-4a6bdfb9baa27e29151c7e97ae2abbe902f53638.zip gdb-4a6bdfb9baa27e29151c7e97ae2abbe902f53638.tar.gz gdb-4a6bdfb9baa27e29151c7e97ae2abbe902f53638.tar.bz2 |
gdb/testsuite: fail if gdb_start_cmd fails
I broke gdb.ada/start.exp, and did not notice it, because it outputs an
UNTESTED if gdb_start_cmd fails. I don't really see when start would
fail and it's not a problem that should be looked at. Change all spots
that call untested after a gdb_start_cmd failure, use fail instead.
Doing so caused some failures with the native-gdbserver board. Some
tests that use "start" were relying on the fact that start would fail
with that board to just return with "untested". Change them to add an
early return if use_gdb_stub returns true.
Some gdb.pascal tests also failed with native-gdbserver, because they
did use gdb_start_cmd to start the inferior, for no good reason.
Convert them to use runto_main instead, which does the right thing if
the target is a stub.
A further refactoring could be to make gdb_start_cmd match the expected
breakpoint hit and the prompt, which it doesn't do currently (it leaves
that to the callers, but not all of them do).
Change-Id: I097370851213e798ff29fb6cf8ba25ef7d2be007
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Diffstat (limited to 'gprof/bbconv.pl')
0 files changed, 0 insertions, 0 deletions