Re: [PATCH] Skipping tests that use remote protocol

[Pedro Alves <palves at redhat dot com>]

I see now we're discussing the same things here:

 https://sourceware.org/ml/gdb-patches/2014-12/msg00507.html

On 12/15/2014 11:58 AM, Yao Qi wrote:

>> [target_info exists use_gdb_stub] alone would work for the attach
>> tests,
> 
> I am afraid not.  attach tests should be skipped on remote host testing
> (build != host, host == target) too, because test program is spawned on
> build, and the corresponding pid (on build) is used for gdb (on host) to
> attach.

As I mentioned in the other email, in that scenario, build != target too,
so an is_remote target check already causes it to be skipped.

In the (build != host, build == target) scenario, the program
is spawned on the target, and although gdb runs on a different
machine from where the target programs run, the PID that is
passed to gdb is a target pid (e.g., debugging with extended-remote).
So in that scenario, the test should be able to run.  But if we
checked "is_remote host", it wouldn't.

>> 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".  

It means "use stub-like mechanisms".  IOW, "when gdb connects,
the program is already running, because the debug agent is really
a piece of code (stub) that runs inside the target program".  GDB used
to support a bunch more remote protocols that we've been dropping
over the years.  And then GDBserver/"target remote" debugging behaves
mostly like a real stub, so nowadays use_gdb_stub is it's mostly
equivalent to "remote", though the former is more generic.

>> 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.

See above.  The extended protocol does not behave like a stub.

>>
>> 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.

True, but what are the cases where that matters?

>> 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).

Agreed.

>>
>> 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.

See https://sourceware.org/ml/gdb-patches/2014-12/msg00507.html.

Thanks,
Pedro Alves