This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: How to abort a test?
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, dejagnu at gnu dot org, gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 14 Jan 2016 16:25:45 +0000
- Subject: Re: How to abort a test?
- Authentication-results: sourceware.org; auth=none
- References: <56958359 dot 8070708 at ericsson dot com>
On 01/12/2016 10:51 PM, Simon Marchi wrote:
> Hi!
>
> (x-posting to gdb-patches@ and/or dejagnu@, depending on the point of view)
>
> I am trying to make some improvements in the gdb testsuite, especially when testing with
> gdbserver on a remote target board. I'd like to add a check so that if the gdbserver
> specified by the user does not exist on the remote board, the test will error out and
> abort. There is no point in testing anything else after that, we know it will fail
> (and take a long of time before doing so, because gdb needs to timeout first).
>
> When raising an exception, such as:
>
> error "The specified gdbserver path does not exist."
>
> I can make it propagate up to where runtest catches it:
>
> runtest.exp:1474: if { [catch "uplevel #0 source $test_file_name"] == 1 } {
>
> The test will be aborted, runtest will output a detailed error, but the test will still
> pass. Intuitively, I would think that a test that throws an error should automatically
> be failed or unresolved, since something unexpected happened.
IIUC, you wouldn't want pass/fail to even be reached, so I don't understand
what test would you want to fail.
>
> The only option I see right now would be to fix the whole return chain and add proper
> error handling everywhere, to exit early when an error happens. However, that means
> changing tens (hundreds?) of callsites through the testsuite, which is why I'm
> looking for alternative solutions first.
Test usually return early if running to main fails (if ![runto_main]), so maybe it
won't be that many places. Maybe some judiciously placed "return -code return"
hacks saves you a good chunk. I don't have any other idea.
For the particular case of gdbserver not being present in the target,
probably the easiest would be to check that earlier, likely before
runtest, even. Not ideal, since the testsuite can mix native and gdbserver
tests, for instance, but...
>
> My situation is actually very similar to this unanswered stackoverflow question, so
> bonus points for us if we can answer it at the same time :)
>
> http://stackoverflow.com/questions/16131622/abort-a-test-in-a-dejagnu-testsuite
>
> It's the first hit when you Google "dejagnu abort test", so I'm sure it would help
> more people.
>
> Thanks for your help,
>
> Simon
>
Thanks,
Pedro Alves