This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Skipping tests that use remote protocol
- From: "Breazeal, Don" <donb at codesourcery dot com>
- To: "Qi, Yao" <Yao_Qi at mentor dot com>, "Breazeal, Don" <Don_Breazeal at mentor dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 12 Dec 2014 11:00:11 -0800
- Subject: Re: [PATCH] Skipping tests that use remote protocol
- Authentication-results: sourceware.org; auth=none
- References: <1418344896-9036-1-git-send-email-donb at codesourcery dot com> <877fxxzhmx dot fsf at codesourcery dot 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