Re: [rfc] Handle lack of non-stop support more gracefully

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:
> On Monday 14 June 2010 15:13:29, Ulrich Weigand wrote:
> > Pedro, it seems you originally added the perror calls -- was there any
> > reason I may be missing why we should need them anyway?
> 
> Sorry, I don't recall.  There was probably no good reason.  I probably
> copied it from what some CLI tests do:
> 
>  if ![runto_main] then {
>    perror "Couldn't run to main"
>    return -1
>  }
> 
> I've no objections to your patch.

OK, thanks.  I've checked the patch in now.

> I took a quick look over mi-support, and I can see how I got a bit confused
> about what do the different return codes leading up to mi_run_to_main mean.
> It looks like some non-gdbserver targets will still trip on
> this problem:
> 
>     } elseif { [target_info gdb_protocol] == "remote" } {
> 	# remote targets
> 	if { [mi_gdb_target_cmd "remote" [target_info netport]] != 0 } {
> 	    perror "Unable to connect to remote target"
> 	    return -1
> 	}
> 
> ?
> 
> Maybe mi_gdb_target_cmd should return a different error code for
> not-supported vs connection error.
> 
> I'm still a bit confused over how the non-stop MI handle this.  If
> 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.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com