[05/14] gdb/testsuite: Skip a few gdb.base/skip.exp tests for remote targets

  From: Anton Kolesov <Anton.Kolesov@synopsys.com>

Few initial tests in gdb.base/skip.exp expect GDB to be in the state where
there is no default file for "skip" command. This is true when debugging
native targets - there is no inferior until "run" command is executed and
thus there is no "default" skip file. However that is not true for remote
targets - after "prepare_for_testing" test procedure GDB is already
connected to the target and has an existing inferior, so "default" file is
set by that time.

gdb/testsuite/ChangeLog:
2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.base/skip.exp: Skip a few tests if remotely connected.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/skip.exp | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)
  

On 2/7/20 11:59 AM, Shahab Vahedi wrote:
> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Few initial tests in gdb.base/skip.exp expect GDB to be in the state where
> there is no default file for "skip" command. This is true when debugging
> native targets - there is no inferior until "run" command is executed and
> thus there is no "default" skip file. However that is not true for remote
> targets - after "prepare_for_testing" test procedure GDB is already
> connected to the target and has an existing inferior, so "default" file is
> set by that time.

This is not what i see with a standard remote gdbserver-based test. For 
board "native-gdbserver" i see all the tests passing just fine.

GDB gets fired up and these first few checks get done without connecting 
to gdbserver. Then GDB proceeds to connect to gdbserver.

This, again, seems to indicate there is some custom board file in your 
setup that is implementing testsuite primitives (that 
prepare_for_testing calls) differently than what is present in GDB's 
testsuite.

Am i missing something?

I think this is also the case with 12/14.
> 
> gdb/testsuite/ChangeLog:
> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/skip.exp: Skip a few tests if remotely connected.
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>   gdb/testsuite/gdb.base/skip.exp | 12 ++++++++----
>   1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp
> index 513c9fcc82ea..31a20c868a2a 100644
> --- a/gdb/testsuite/gdb.base/skip.exp
> +++ b/gdb/testsuite/gdb.base/skip.exp
> @@ -30,10 +30,14 @@ set srcfile skip.c
>   set srcfile1 skip1.c
>   
>   # Right after we start gdb, there's no default file or function to skip.
> -
> -gdb_test "skip file" "No default file now." "skip file (no default file)"
> -gdb_test "skip function" "No default function now."
> -gdb_test "skip" "No default function now." "skip (no default function)"
> +# However that is not true for remote targets - after "prepare_for_testing" GDB
> +# is already connected to the target and has a valid inferior, hence default
> +# file.
> +if ![use_gdb_stub] {
> +    gdb_test "skip file" "No default file now." "skip file (no default file)"
> +    gdb_test "skip function" "No default function now."
> +    gdb_test "skip" "No default function now." "skip (no default function)"
> +}
>   
>   # Test elided args.
>   
>
  

On 2/11/20 9:20 AM, Luis Machado wrote:
> On 2/7/20 11:59 AM, Shahab Vahedi wrote:

>> From: Anton Kolesov <Anton.Kolesov@synopsys.com>

>>

>> Few initial tests in gdb.base/skip.exp expect GDB to be in the state where

>> there is no default file for "skip" command. This is true when debugging

>> native targets - there is no inferior until "run" command is executed and

>> thus there is no "default" skip file. However that is not true for remote

>> targets - after "prepare_for_testing" test procedure GDB is already

>> connected to the target and has an existing inferior, so "default" file is

>> set by that time.

> 

> This is not what i see with a standard remote gdbserver-based test. For board "native-gdbserver" i see all the tests passing just fine.

> 

> GDB gets fired up and these first few checks get done without connecting to gdbserver. Then GDB proceeds to connect to gdbserver.

> 

> This, again, seems to indicate there is some custom board file in your setup that is implementing testsuite primitives (that prepare_for_testing calls) differently than what is present in GDB's testsuite.

> 

> Am i missing something?


Anton, could you share your experience with us?

> 

> I think this is also the case with 12/14.

>>

>> gdb/testsuite/ChangeLog:

>> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>

>>

>>     * gdb.base/skip.exp: Skip a few tests if remotely connected.

>>

>> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>

>> ---

>>   gdb/testsuite/gdb.base/skip.exp | 12 ++++++++----

>>   1 file changed, 8 insertions(+), 4 deletions(-)

>>

>> diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp

>> index 513c9fcc82ea..31a20c868a2a 100644

>> --- a/gdb/testsuite/gdb.base/skip.exp

>> +++ b/gdb/testsuite/gdb.base/skip.exp

>> @@ -30,10 +30,14 @@ set srcfile skip.c

>>   set srcfile1 skip1.c

>>     # Right after we start gdb, there's no default file or function to skip.

>> -

>> -gdb_test "skip file" "No default file now." "skip file (no default file)"

>> -gdb_test "skip function" "No default function now."

>> -gdb_test "skip" "No default function now." "skip (no default function)"

>> +# However that is not true for remote targets - after "prepare_for_testing" GDB

>> +# is already connected to the target and has a valid inferior, hence default

>> +# file.

>> +if ![use_gdb_stub] {

>> +    gdb_test "skip file" "No default file now." "skip file (no default file)"

>> +    gdb_test "skip function" "No default function now."

>> +    gdb_test "skip" "No default function now." "skip (no default function)"

>> +}

>>     # Test elided args.

>>
  

> >

> > This is not what i see with a standard remote gdbserver-based test. For board

> "native-gdbserver" i see all the tests passing just fine.

> >

> > GDB gets fired up and these first few checks get done without connecting to

> gdbserver. Then GDB proceeds to connect to gdbserver.

> >

> > This, again, seems to indicate there is some custom board file in your setup

> that is implementing testsuite primitives (that prepare_for_testing calls)

> differently than what is present in GDB's testsuite.

> >

> > Am i missing something?

> 

> Anton, could you share your experience with us?

> 


I don't remember the details, but if I read that correctly, the fix assumes
that checks are done after connecting to the target. Perhaps the behavior has
changed since the patch has been authored? We do use custom board, but I
don't think it modifies test procedures like prepare_for_testing. It does
however implement board specific open, close, and reboot procs, and for one
server we implement custom gdb_comm_leave proc to ensure that each test is run
with a new GDB instance, because GDB-instance reuse was causing troubles in
some cases: 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-releases/dejagnu/nsim-extra.exp#L121
  

* Anton Kolesov <Anton.Kolesov@synopsys.com> [2020-02-25 08:39:16 +0000]:

> > >
> > > This is not what i see with a standard remote gdbserver-based test. For board
> > "native-gdbserver" i see all the tests passing just fine.
> > >
> > > GDB gets fired up and these first few checks get done without connecting to
> > gdbserver. Then GDB proceeds to connect to gdbserver.
> > >
> > > This, again, seems to indicate there is some custom board file in your setup
> > that is implementing testsuite primitives (that prepare_for_testing calls)
> > differently than what is present in GDB's testsuite.
> > >
> > > Am i missing something?
> > 
> > Anton, could you share your experience with us?
> > 
> 
> I don't remember the details, but if I read that correctly, the fix assumes
> that checks are done after connecting to the target. Perhaps the behavior has
> changed since the patch has been authored? We do use custom board, but I
> don't think it modifies test procedures like prepare_for_testing. It does
> however implement board specific open, close, and reboot procs, and for one
> server we implement custom gdb_comm_leave proc to ensure that each test is run
> with a new GDB instance, because GDB-instance reuse was causing troubles in
> some cases: 
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-releases/dejagnu/nsim-extra.exp#L121

I'd be interested to know where you're doing the connect to a remote
type logic that it's getting triggered from 'prepare_for_testing'.  My
first instinct is to say that's being done in the wrong place, but
maybe there's a really good reason (TM), but I don't think we should
modify this test until we understand what the reasoning is here.

Thanks,
Andrew