This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] gdb.mi/mi-info-os.exp: Fix cross-debugger testing
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>, Stan Shebs <stan at codesourcery dot com>
- Date: Wed, 20 Nov 2013 20:01:16 +0000
- Subject: Re: [PATCH] gdb.mi/mi-info-os.exp: Fix cross-debugger testing
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 1 dot 10 dot 1311010106300 dot 12843 at tp dot orcam dot me dot uk> <528D0AE0 dot 50702 at redhat dot com>
On Wed, 20 Nov 2013, Pedro Alves wrote:
> > Index: gdb-fsf-trunk-quilt/gdb/testsuite/gdb.mi/mi-info-os.exp
> > ===================================================================
> > --- gdb-fsf-trunk-quilt.orig/gdb/testsuite/gdb.mi/mi-info-os.exp 2013-11-01 00:52:48.000000000 +0000
> > +++ gdb-fsf-trunk-quilt/gdb/testsuite/gdb.mi/mi-info-os.exp 2013-11-01 00:56:43.588756235 +0000
> > @@ -33,6 +33,20 @@ if [mi_gdb_start] {
> > continue
> > }
> >
> > +# In non-native configurations we need to have a live target.
> > +if { ![isnative] } {
>
> Shouldn't this be [is_remote target] ? isnative just compares
> the _build_ and target triplets.
Well is_remote merely checks if the target board is not the same as the
local (build) machine. I don't think it matters, it doesn't tell anything
about GDB configuration, e.g. GDB might be native after all, running on a
remote host that is the same as the target (i.e. no `gdbserver' or
suchlike involved, although we don't actually care here whether
`gdbserver' is used or not), like in a crossed build of a native
toolchain.
FWIW I actually scanned our testsuite for various configuration
conditions used before making this change and I believe the cases of
[is_remote target] I saw are incorrect -- the authors of the pieces of
code in question appear to have assumed that this condition translates to
the use of the RSP and `gdbserver' while it is not what DejaGNU
implements. All it implies is what I noted above -- that is that the
target machine is not the same as the build machine (one running `make
check' or the equivalent). That has nothing to do with `gdbserver' or the
use of the RSP.
> (And even if host and target triplets matched, we could still
> have a configuration without a native target)
How come?
> Otherwise OK.
So what is your proposal? What's the proper way of determining whether
this configuration of GDB is native (includes a native target) or not?
To maintain current coverage we need to complement the check made in
target_get_osdata:
if (current_target.to_stratum >= process_stratum)
t = current_target.beneath;
else
t = find_default_run_target ("get OS data");
and do not connect to any target in configurations where
find_default_run_target returns success.
Maciej