This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gdb.mi/mi-info-os.exp: Fix cross-debugger testing


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]