Re: [PATCH] Skipping tests that use remote protocol

["Breazeal, Don" <donb@codesourcery.com>]

On 12/11/2014 7:11 PM, Qi, Yao wrote:
> Don Breazeal <donb@codesourcery.com> writes:
> 
>> Other procedures are also used that don't really check the right thing.
>>
>> * isnative checks the build triplet against the target triplet.
>>
>> * gdb_is_target_remote and target_is_gdbserver don't differentiate between
>>   remote and extended-remote.  Both require GDB to be running, which makes
>>   using them to skip a test less efficient than a procedure that uses info
>>   from the target board config file.
>>
>> * target_info use_gdb_stub is used in lib/gdb.exp to explicitly determine
>>   if a target is remote and not extended-remote.
>>
>> If we reach consensus on this approach I'll follow up with patches to
>> convert other tests to use these procedures instead of is_remote,
>> isnative, and so on.
> 
> Does "![isnative] || [is_remote host] || [target_info exists use_gdb_stub]"
> work for you?  It is used in some attach related tests.
> 
Hm. This would work for my attach example, but I don't think that this
check is sufficient for all cases (e.g. gdb.base/catch-syscall.exp,
which we want to skip for both "remote" and "extended-remote" on Linux).

[target_info exists use_gdb_stub] alone would work for the attach tests,
which we want to skip for remote but run for extended-remote.  This
(use_gdb_stub) seems to be equivalent to my new proc
[gdb_using_remote_protocol], meaning "using gdbserver/stub" and protocol
== "remote".  The name use_gdb_stub is misleading, since it is only set
for the remote protocol and not the extended protocol.  Things go wrong
in lib/gdb.exp if you set use_gdb_stub and run extended-mode tests.

If we put aside the fact that we can control the results of is_remote by
setting the variable isremote in the board file, then [isnative] and
[is_remote] don't provide the information we really need.  In the
example above they are checking whether build!=target and build!=host,
respectively.  That doesn't cover all the cases, e.g. if build != target
and build != host, we don't know for sure whether target == host.

We can set isremote in the board files, as in native-gdbserver.exp, to
control what is_remote returns.  But checking if we are using gdbserver
or a stub is not the purpose of is_remote, and trying to use it in
general for that could have negative side-effects (e.g. to gcc tests).

My conclusion from all of this is that we should never use isnative or
is_remote to decide whether to skip tests for remote targets.  The two
new proc's are testing the specific conditions that affect the remote
tests.  We could use [target_info exists use_gdb_stub] in place of
[gdb_using_remote_protocol], but the name may be misleading.

What do you think?  In any case I'd like this discussion to result in a
standard approach for skipping remote tests for each of the relevant cases.

Thanks!
--Don