This is the mail archive of the
mailing list for the GDB project.
Re: [rfc] Handle lack of non-stop support more gracefully
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Date: Mon, 14 Jun 2010 16:59:02 +0100
- Subject: Re: [rfc] Handle lack of non-stop support more gracefully
- References: <201006141549.o5EFnuGE029348@d12av02.megacenter.de.ibm.com>
On Monday 14 June 2010 16:49:56, Ulrich Weigand wrote:
> > I'm still a bit confused over how the non-stop MI handle this. If
(for the record, I meant "the all-stop MI tests" here.)
> > mi_gdb_target_cmd fails to connect, it seems to return 0 anyway, so
> > the following tests will just cascade in FAILs. For other, non-remote
> > targets, mi_gdb_target_load will call perror on connection fail, but
> > the gdbserver branch at the top doesn't.
> I would suggest that just about any use of perror is wrong here. If
> the underlying library routine detects any condition that makes the
> rest of the test execution impossible, it should itself issue an
> appropriate test status, which would usually be FAIL (if the condition
> is due to a GDB bug), UNSUPPORTED (if it is due to some feature not
> available on the platform), or UNRESOLVED (if it is due to some setup
> or other external issue, like the target connection failing).
> Then, the library should return an error code that causes the main
> test case to silently stop any further test execution.
Thanks. Sounds like a good plan.