Re: [PATCH] Skipping tests that use remote protocol

[Yao Qi <yao at codesourcery dot com>]

"Breazeal, Don" <donb@codesourcery.com> writes:

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

I'd like tests automatically detect whether syscall catchpoint is
supported, instead of hard-coded some unsupported targets.  We can
insert a syscall catchpoint and resume the inferior, warning

"warning: Error inserting catchpoint 2: Your system does not support this type"

can tell us that syscall cachtpoint isn't supported.  It is similar for
detecting tracepoint support.

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

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

Some tests have to be skipped on remote targets, and even on other
targets.  I'd like to list all of them (tests having troubles running on
remote target), and then figure out how to fix them.  We can use a
standard approach if necessary.

-- 
Yao (éå)