aboutsummaryrefslogtreecommitdiff
path: root/opcodes/or1k-opc.h
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2020-08-24 19:44:53 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2020-08-24 19:44:53 -0400
commit60122dbef4eb01b634019bd71ef47dec8faab274 (patch)
tree41efea1fbc546fdb429f59216e8ea1267f628157 /opcodes/or1k-opc.h
parentc426fddb87d29034b50c2433e12a08aa23b7fb9f (diff)
downloadgdb-60122dbef4eb01b634019bd71ef47dec8faab274.zip
gdb-60122dbef4eb01b634019bd71ef47dec8faab274.tar.gz
gdb-60122dbef4eb01b634019bd71ef47dec8faab274.tar.bz2
gdb/testsuite: make runto always emit a FAIL on internal error
I noticed that when a test uses `runto_main` and a GDB internal error happens while running to main, no error or fail is emitted. This is because `runto_main` uses the `no-message` option of `runto`. As a result, if a test fails to run to main and exits, no sign that something went wrong is emitted. For example, add this always-false assertion to compute_frame_id: --- a/gdb/frame.c +++ b/gdb/frame.c @@ -545,6 +545,7 @@ static void compute_frame_id (struct frame_info *fi) { gdb_assert (!fi->this_id.p); + gdb_assert (false); if (frame_debug) fprintf_unfiltered (gdb_stdlog, "{ compute_frame_id (fi=%d) ", ... and run gdb.dwarf2/dw2-align.exp. No fail or sign that something went wrong is shown. It just appears as if the test gets skipped. A developer introducing such a regression in this test today would likely notice it, because we are used to diff-ing test results. So we would see some PASSes dispappear for no good reason and look into it. But I find it worrysome for two reasons: 1. Scripts that analyze regressions (such as the one on the buildbot) may only look for new FAILs or new ERRORs. It would probably miss this. 2. Imagine that we one day have a testsuite that runs cleanly (some people might already run subsets of the testsuite and expect it to all pass), we would just run the testsuite and check that there are no fails. It would be easy to miss something like this. In case of internal error, I suggest making `runto` emit a FAIL even if `no-message` was passed. This is different from other failure modes that might be expected (whchi rightfully cause the test to simply be skipped). An internal error is always bad, so if it happens it should noisily fail. gdb/testsuite/ChangeLog: * lib/gdb.exp (runto): Always emit fail on internal error. Change-Id: I6e6faed4868ea821541a23042b2d01c30058b0d3
Diffstat (limited to 'opcodes/or1k-opc.h')
0 files changed, 0 insertions, 0 deletions