[PATCH 00/14] Fixes for GDB Testsuites

[PATCH 00/14] Fixes for GDB Testsuites

[Shahab Vahedi]

From: Shahab Vahedi <shahab@synopsys.com>

This is a set of patches mostly for adapting the tests as such to handle
the executions through a gdb server better.  We have  encountered  these
issues while running the tests for ARC, but I believe other targets  can
benefit from them.

I have  run  "make  check-gdb"  for  x86_64  target  and  there  was  no
regression.

Anton Kolesov (14):
  gdb/testsuite: Fix an invalid is_remote check in fileio test
  gdb/testsuite: Skip fileio.exp for remote targets
  gdb/testsuite: Add exit_is_reliable proc
  gdb/testsuite: Avoid fake failures when exit is unreliable
  gdb/testsuite: Skip a few gdb.base/skip.exp tests for remote targets
  gdb/testsuite: Fix gdb.mi exit function
  gdb/testsuite: Fix invalid watchpoint test in mi suite
  gdb/testsuite: Fix bug in break-unload-file
  gdb/testsuite: Fix break-always.exp for enabled do_reload_on_run
  gdb/testsuite: Fix gdb.base/chng-syms.exp for remote target
  gdb/testsuite: Fix dbx.exp for remote targets
  gdb/testsuite: Skip on of the interp.exp test for remote targets
  gdb/testsuite: Skip killed-outside when nosignals
  gdb/testsuite: Skip some compile.exp tests when running with gdb-comm board

 gdb/testsuite/config/monitor.exp             |  8 +++++++
 gdb/testsuite/gdb.base/break-always.exp      | 10 ++++++--
 gdb/testsuite/gdb.base/break-unload-file.exp |  2 +-
 gdb/testsuite/gdb.base/callexit.exp          |  7 ++++++
 gdb/testsuite/gdb.base/commands.exp          | 14 +++++++++++
 gdb/testsuite/gdb.base/dbx.exp               |  6 +++++
 gdb/testsuite/gdb.base/ena-dis-br.exp        | 18 ++++++++------
 gdb/testsuite/gdb.base/fileio.exp            |  5 +++-
 gdb/testsuite/gdb.base/hook-stop.exp         | 12 +++++++++-
 gdb/testsuite/gdb.base/interp.exp            | 20 +++++++++-------
 gdb/testsuite/gdb.base/killed-outside.exp    |  5 ++++
 gdb/testsuite/gdb.base/nextoverexit.exp      |  7 ++++++
 gdb/testsuite/gdb.base/skip.exp              | 12 ++++++----
 gdb/testsuite/gdb.compile/compile.exp        | 25 +++++++++++---------
 gdb/testsuite/gdb.mi/basics.c                |  2 +-
 gdb/testsuite/gdb.mi/mi-break.exp            | 10 ++++++++
 gdb/testsuite/gdb.mi/mi-cli.exp              | 15 +++++++-----
 gdb/testsuite/gdb.mi/mi-exit-code.exp        |  5 ++++
 gdb/testsuite/gdb.mi/mi-simplerun.exp        |  5 ++++
 gdb/testsuite/gdb.mi/mi-watch.exp            |  5 ++++
 gdb/testsuite/lib/gdb.exp                    | 18 ++++++++------
 gdb/testsuite/lib/mi-support.exp             |  7 ++++++
 22 files changed, 169 insertions(+), 49 deletions(-)

-- 
2.25.0

[PATCH 06/14] gdb/testsuite: Fix gdb.mi exit function

[Shahab Vahedi]

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

There was a bug in gdb.mi tests where GDB was trying to connect to same
GDBserver twice, because first instance wasn't properly killed after test is
finished. That was happening with tests that run MI in a separate tty. Spawn
id of this second UI was set as a default spawn_id of this application,
however function "exp_pid" couldn't return a valid process ID for that
spawn_id. As a result standard_close, invoked from gdb_exit failed to kill
GDB process by PID. This patch fixes this problem by making sure that
mi_gdb_exit will set current spawn_id to the ID of the main GDB tty, so that
exp_pid will work and GDB will be killed. This patch also adds explicit
invocation of mi_gdb_exit to the end of mi-break.exp tests, because those
tests use separate tty for MI, so should use mi_gdb_exit, but by default
runtest invokes gdb_exit when .exp file is finished, not the mi_gdb_exit.

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

	* gdb.mi/mi-break.exp (test_break): Explicitly exit the MI gdb.
	* gdb.mi/mi-watch.exp (test_watchpoint_all): Likewise.
	* lib/mi-support.exp (mi_uncatched_gdb_exit): Switch back to
	"main spawn id" before "remote_close".

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.mi/mi-break.exp | 5 +++++
 gdb/testsuite/gdb.mi/mi-watch.exp | 5 +++++
 gdb/testsuite/lib/mi-support.exp  | 7 +++++++
 3 files changed, 17 insertions(+)

diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp
index acec246f52ee..925a08e7190a 100644
--- a/gdb/testsuite/gdb.mi/mi-break.exp
+++ b/gdb/testsuite/gdb.mi/mi-break.exp
@@ -432,6 +432,11 @@ proc test_break {mi_mode} {
     test_abreak_creation
 
     test_explicit_breakpoints
+
+    # If separate-mi-tty is used, GDB will not be properly closed by the
+    # default gdb_exit, which is called by default when .exp file is finished.
+    # Instead a mi_gdb_exit must be used.
+    mi_gdb_exit
 }
 
 if [gdb_debug_enabled] {
diff --git a/gdb/testsuite/gdb.mi/mi-watch.exp b/gdb/testsuite/gdb.mi/mi-watch.exp
index fe09f1dea404..1545f39bdc78 100644
--- a/gdb/testsuite/gdb.mi/mi-watch.exp
+++ b/gdb/testsuite/gdb.mi/mi-watch.exp
@@ -172,6 +172,11 @@ proc test_watchpoint_all {mi_mode type} {
     #test_rwatch_creation_and_listing
     #test_awatch_creation_and_listing
     test_watchpoint_triggering
+
+    # If separate-mi-tty is used, GDB will not be properly closed by the
+    # default gdb_exit, which is called by default when .exp file is finished.
+    # Instead a mi_gdb_exit must be used.
+    mi_gdb_exit
 }
 
 if [gdb_debug_enabled] {
diff --git a/gdb/testsuite/lib/mi-support.exp b/gdb/testsuite/lib/mi-support.exp
index 2c67cc287dce..922b021099ac 100644
--- a/gdb/testsuite/lib/mi-support.exp
+++ b/gdb/testsuite/lib/mi-support.exp
@@ -91,6 +91,13 @@ proc mi_uncatched_gdb_exit {} {
     }
 
     if ![is_remote host] {
+	# DejaGNU's standard_close uses spawn_id to figure out PID through
+	# exp_pid and then kill process by ID. However, when MI runs on
+	# secondary UI exp_pid returns nothing for it's spawn_id, so we have to
+	# switch back to the main spawn_id for remote_close to succeed.
+	if { $gdb_main_spawn_id != $gdb_spawn_id } {
+	    switch_gdb_spawn_id $gdb_main_spawn_id
+	}
 	remote_close host
     }
     unset gdb_spawn_id
-- 
2.25.0

[PATCH 09/14] gdb/testsuite: Fix break-always.exp for enabled do_reload_on_run

[Shahab Vahedi]

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

GDB testsuite proc "runto" is not compatible with "always-inserted on"
when gdb,do_reload_on_run is set - in this case "runto" will insert
breakpoint, and then will do a reload, which will overwrite an already
inserted breakpoint, so further continue will not succeed. There is no
problem with "always-inserted off", because breakpoints are inserted
automatically by GDB before resuming, so reloading doesn't overwrite
them.

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

	* gdb.base/break-always.exp: Move "runto" before
	"always-inserted on".

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

diff --git a/gdb/testsuite/gdb.base/break-always.exp b/gdb/testsuite/gdb.base/break-always.exp
index b2a2f3a475cb..c3b55b9f8402 100644
--- a/gdb/testsuite/gdb.base/break-always.exp
+++ b/gdb/testsuite/gdb.base/break-always.exp
@@ -21,6 +21,14 @@ if { [prepare_for_testing "failed to prepare" break-always break-always.c] } {
     return -1
 }
 
+# GDB testsuite proc "runto" is not compatible with "always-inserted on" when
+# gdb,do_reload_on_run is set - in this case "runto" will insert breakpoint,
+# and then will do a reload, which will overwrite an already inserted
+# breakpoint, so further continue will not succeed. There is no problem with
+# "always-inserted off", because breakpoints are inserted automatically by GDB
+# before resuming, so reloading doesn't overwrite them.
+runto foo
+
 set bar_location [gdb_get_line_number "break in bar" break-always.c]
 
 gdb_test_no_output "set breakpoint always-inserted on"
@@ -28,8 +36,6 @@ gdb_test_no_output "set breakpoint always-inserted on"
 gdb_test "show breakpoint always-inserted" "mode is on\." \
     "confirm breakpoint always-inserted"
 
-runto foo
-
 gdb_test "break bar" "Breakpoint 2.*" "set breakpoint on bar"
 gdb_test "break bar" "Note: breakpoint 2 also set.*Breakpoint 3.*" "set 2nd breakpoint on bar"
 gdb_test "break bar" "Note: breakpoints 2 and 3 also set.*Breakpoint 4.*" "set 3rd breakpoint on bar"
-- 
2.25.0

[PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is unreliable

[Shahab Vahedi]

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

Tests that run in background will not run properly with targets that
doesn't have a proper "exit" function. For example, gdb.base/hook-stop
expects that after hook will resume inferior in background, there would
be a message "exited normally", however such a message will appear only
for targets with a proper exit(), while others will, for example, spin
in the infinite loop.

Test gdb.base/nextoverexit expects message "inferior exited normally",
which is present only when exit() actually halts the target.

Some tests in gdb.base/commands.exp has a flow that expects that
application can exit itself, which is not true when exit() function is
not reliable.

This patch makes those tests conditional - they run only if exit is
reliable.

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

	* gdb.base/callexit.exp: Expect an "exit()" only if
	"exit_is_reliable" says so.
	* gdb.base/commands.exp: Likewise.
	* gdb.base/ena-dis-br.exp: Likewise.
	* gdb.base/hook-stop.exp: Likewise.
	* gdb.base/nextoverexit.exp: Likewise.
	* gdb.mi/mi-break.exp: Likewise.
	* gdb.mi/mi-exit-code.exp: Likewise.
	* gdb.mi/mi-simplerun.exp: Likewise.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/callexit.exp     |  7 +++++++
 gdb/testsuite/gdb.base/commands.exp     | 14 ++++++++++++++
 gdb/testsuite/gdb.base/ena-dis-br.exp   | 18 +++++++++++-------
 gdb/testsuite/gdb.base/hook-stop.exp    | 12 +++++++++++-
 gdb/testsuite/gdb.base/nextoverexit.exp |  7 +++++++
 gdb/testsuite/gdb.mi/mi-break.exp       |  5 +++++
 gdb/testsuite/gdb.mi/mi-exit-code.exp   |  5 +++++
 gdb/testsuite/gdb.mi/mi-simplerun.exp   |  5 +++++
 8 files changed, 65 insertions(+), 8 deletions(-)

diff --git a/gdb/testsuite/gdb.base/callexit.exp b/gdb/testsuite/gdb.base/callexit.exp
index 67ff48283646..4fc2d5a2669a 100644
--- a/gdb/testsuite/gdb.base/callexit.exp
+++ b/gdb/testsuite/gdb.base/callexit.exp
@@ -28,6 +28,13 @@ if [target_info exists gdb,cannot_call_functions] {
     continue
 }
 
+# Some targets (for example baremetal ones) doesn't have exit() that actually
+# exits anywhere.
+if ![exit_is_reliable] {
+    unsupported "This target doesn't have reliable exit() function."
+    continue
+}
+
 # Start with a fresh gdb.
 
 clean_restart ${binfile}
diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
index 869d0a81a4a7..fd92b3fa3111 100644
--- a/gdb/testsuite/gdb.base/commands.exp
+++ b/gdb/testsuite/gdb.base/commands.exp
@@ -694,6 +694,13 @@ proc_with_prefix deprecated_command_test {} {
 proc_with_prefix bp_deleted_in_command_test {} {
     global gdb_prompt
 
+    # Flow of this test assumes that application will halt after reaching the
+    # exit() function.
+    if ![exit_is_reliable] {
+	unsupported "Function exit() is not reliable on this board."
+	return 0
+    }
+
     delete_breakpoints
 
     # Create a breakpoint, and associate a command-list to it, with
@@ -736,6 +743,13 @@ proc_with_prefix bp_deleted_in_command_test {} {
 }
 
 proc_with_prefix temporary_breakpoint_commands {} {
+    # Flow of this test assumes that application will halt after reaching the
+    # exit() function.
+    if ![exit_is_reliable] {
+	unsupported "Function exit() is not reliable on this board."
+	return 0
+    }
+
     delete_breakpoints
 
     # Create a temporary breakpoint, and associate a commands list to it.
diff --git a/gdb/testsuite/gdb.base/ena-dis-br.exp b/gdb/testsuite/gdb.base/ena-dis-br.exp
index c338a0d51fa9..bf670cbae948 100644
--- a/gdb/testsuite/gdb.base/ena-dis-br.exp
+++ b/gdb/testsuite/gdb.base/ena-dis-br.exp
@@ -295,13 +295,17 @@ gdb_test "continue 2" \
 gdb_test "next" ".*$bp_location11\[ \t\]*marker1.*" \
     "step after continue with ignore count"
 
-set test "continue with ignore count, not stopped at bpt"
-gdb_test_multiple "continue 2" "$test" {
-    -re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
-	pass "$test"
-    }
-    -re "No breakpoint number -1.*$gdb_prompt $" {
-	kfail gdb/1689 "$test"
+# Application is expected to reach an exit() here, so this can't be run if exit
+# is not working.
+if [exit_is_reliable] {
+    set test "continue with ignore count, not stopped at bpt"
+    gdb_test_multiple "continue 2" "$test" {
+	-re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
+	    pass "$test"
+	}
+	-re "No breakpoint number -1.*$gdb_prompt $" {
+	    kfail gdb/1689 "$test"
+	}
     }
 }
 
diff --git a/gdb/testsuite/gdb.base/hook-stop.exp b/gdb/testsuite/gdb.base/hook-stop.exp
index 6b49e39b7380..c9bc3d3b6438 100644
--- a/gdb/testsuite/gdb.base/hook-stop.exp
+++ b/gdb/testsuite/gdb.base/hook-stop.exp
@@ -165,5 +165,15 @@ proc hook_stop_next {} {
 hook_stop_before_frame
 hook_stop_kill
 hook_stop_continue_fg
-hook_stop_continue_bg
+
+# Tests that run in background will not run properly with targets that
+# doesn't have a proper "exit" function. For example, this particular
+# test expects that after hook will resume inferior in background, there
+# would be a message "exited normally", however such a message will
+# appear only for targets with a proper # exit(), while others will, for
+# example, spin in the infinite loop.
+if [exit_is_reliable] {
+    hook_stop_continue_bg
+}
+
 hook_stop_next
diff --git a/gdb/testsuite/gdb.base/nextoverexit.exp b/gdb/testsuite/gdb.base/nextoverexit.exp
index 30eafef675ff..fcea35762b00 100644
--- a/gdb/testsuite/gdb.base/nextoverexit.exp
+++ b/gdb/testsuite/gdb.base/nextoverexit.exp
@@ -14,6 +14,13 @@
 
 standard_testfile
 
+# This tests expects message "inferior exited normally", which is present only
+# when exit() actually halts the target.
+if ![exit_is_reliable] {
+    unsupported "Function exit() is not reliable on this board."
+    return 0
+}
+
 if {[prepare_for_testing "failed to prepare" $testfile $testfile.c]} {
     return -1
 }
diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp
index 1149bb34c8dc..acec246f52ee 100644
--- a/gdb/testsuite/gdb.mi/mi-break.exp
+++ b/gdb/testsuite/gdb.mi/mi-break.exp
@@ -244,6 +244,11 @@ proc test_disabled_creation {} {
 proc test_breakpoint_commands {} {
     global line_callee2_body
 
+    if ![exit_is_reliable] {
+	unsupported "This test requires working exit() function."
+	return 0
+    }
+
     set bp_no_script \
 	[mi_create_breakpoint "basics.c:callee2" \
 	     "breakpoint commands: insert breakpoint at basics.c:callee2" \
diff --git a/gdb/testsuite/gdb.mi/mi-exit-code.exp b/gdb/testsuite/gdb.mi/mi-exit-code.exp
index f10b49cee0f8..fb5c693597da 100644
--- a/gdb/testsuite/gdb.mi/mi-exit-code.exp
+++ b/gdb/testsuite/gdb.mi/mi-exit-code.exp
@@ -23,6 +23,11 @@ if [mi_gdb_start] {
 
 standard_testfile
 
+if ![exit_is_reliable] {
+    unsupported "Function exit() is not reliable on this board."
+    return 0
+}
+
 if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
     untested "failed to compile"
     return -1
diff --git a/gdb/testsuite/gdb.mi/mi-simplerun.exp b/gdb/testsuite/gdb.mi/mi-simplerun.exp
index 20a079ead896..ce19122803da 100644
--- a/gdb/testsuite/gdb.mi/mi-simplerun.exp
+++ b/gdb/testsuite/gdb.mi/mi-simplerun.exp
@@ -177,6 +177,11 @@ proc test_program_termination {} {
     # -exec-abort
     # (normal termination of inferior)
 
+    if ![exit_is_reliable] {
+	unsupported "Function exit() is not reliable on this board."
+	return
+    }
+
     mi_execute_to "exec-continue" "exited-normally" "" "" "" "" "" "continue to end"
 }
 
-- 
2.25.0

Re: [PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is unreliable

[Luis Machado]

Hi,

On 2/7/20 11:59 AM, Shahab Vahedi wrote:
> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Tests that run in background will not run properly with targets that
> doesn't have a proper "exit" function. For example, gdb.base/hook-stop
> expects that after hook will resume inferior in background, there would
> be a message "exited normally", however such a message will appear only
> for targets with a proper exit(), while others will, for example, spin
> in the infinite loop.
> 
> Test gdb.base/nextoverexit expects message "inferior exited normally",
> which is present only when exit() actually halts the target.
> 
> Some tests in gdb.base/commands.exp has a flow that expects that
> application can exit itself, which is not true when exit() function is
> not reliable.
> 
> This patch makes those tests conditional - they run only if exit is
> reliable.

I don't know about this one. Doesn't your debugging stub have a way of 
detecting a call to exit, for example?

These changes seem to indicate you are using some custom/modified 
dejagnu board to run your tests. Is your target a qemu/probe that gdb 
connects to and then does the tests?

> 
> gdb/testsuite/ChangeLog:
> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/callexit.exp: Expect an "exit()" only if
> 	"exit_is_reliable" says so.
> 	* gdb.base/commands.exp: Likewise.
> 	* gdb.base/ena-dis-br.exp: Likewise.
> 	* gdb.base/hook-stop.exp: Likewise.
> 	* gdb.base/nextoverexit.exp: Likewise.
> 	* gdb.mi/mi-break.exp: Likewise.
> 	* gdb.mi/mi-exit-code.exp: Likewise.
> 	* gdb.mi/mi-simplerun.exp: Likewise.
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>   gdb/testsuite/gdb.base/callexit.exp     |  7 +++++++
>   gdb/testsuite/gdb.base/commands.exp     | 14 ++++++++++++++
>   gdb/testsuite/gdb.base/ena-dis-br.exp   | 18 +++++++++++-------
>   gdb/testsuite/gdb.base/hook-stop.exp    | 12 +++++++++++-
>   gdb/testsuite/gdb.base/nextoverexit.exp |  7 +++++++
>   gdb/testsuite/gdb.mi/mi-break.exp       |  5 +++++
>   gdb/testsuite/gdb.mi/mi-exit-code.exp   |  5 +++++
>   gdb/testsuite/gdb.mi/mi-simplerun.exp   |  5 +++++
>   8 files changed, 65 insertions(+), 8 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/callexit.exp b/gdb/testsuite/gdb.base/callexit.exp
> index 67ff48283646..4fc2d5a2669a 100644
> --- a/gdb/testsuite/gdb.base/callexit.exp
> +++ b/gdb/testsuite/gdb.base/callexit.exp
> @@ -28,6 +28,13 @@ if [target_info exists gdb,cannot_call_functions] {
>       continue
>   }
>   
> +# Some targets (for example baremetal ones) doesn't have exit() that actually
> +# exits anywhere.
> +if ![exit_is_reliable] {
> +    unsupported "This target doesn't have reliable exit() function."
> +    continue
> +}
> +
>   # Start with a fresh gdb.
>   
>   clean_restart ${binfile}
> diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
> index 869d0a81a4a7..fd92b3fa3111 100644
> --- a/gdb/testsuite/gdb.base/commands.exp
> +++ b/gdb/testsuite/gdb.base/commands.exp
> @@ -694,6 +694,13 @@ proc_with_prefix deprecated_command_test {} {
>   proc_with_prefix bp_deleted_in_command_test {} {
>       global gdb_prompt
>   
> +    # Flow of this test assumes that application will halt after reaching the
> +    # exit() function.
> +    if ![exit_is_reliable] {
> +	unsupported "Function exit() is not reliable on this board."
> +	return 0
> +    }
> +
>       delete_breakpoints
>   
>       # Create a breakpoint, and associate a command-list to it, with
> @@ -736,6 +743,13 @@ proc_with_prefix bp_deleted_in_command_test {} {
>   }
>   
>   proc_with_prefix temporary_breakpoint_commands {} {
> +    # Flow of this test assumes that application will halt after reaching the
> +    # exit() function.
> +    if ![exit_is_reliable] {
> +	unsupported "Function exit() is not reliable on this board."
> +	return 0
> +    }
> +
>       delete_breakpoints
>   
>       # Create a temporary breakpoint, and associate a commands list to it.
> diff --git a/gdb/testsuite/gdb.base/ena-dis-br.exp b/gdb/testsuite/gdb.base/ena-dis-br.exp
> index c338a0d51fa9..bf670cbae948 100644
> --- a/gdb/testsuite/gdb.base/ena-dis-br.exp
> +++ b/gdb/testsuite/gdb.base/ena-dis-br.exp
> @@ -295,13 +295,17 @@ gdb_test "continue 2" \
>   gdb_test "next" ".*$bp_location11\[ \t\]*marker1.*" \
>       "step after continue with ignore count"
>   
> -set test "continue with ignore count, not stopped at bpt"
> -gdb_test_multiple "continue 2" "$test" {
> -    -re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
> -	pass "$test"
> -    }
> -    -re "No breakpoint number -1.*$gdb_prompt $" {
> -	kfail gdb/1689 "$test"
> +# Application is expected to reach an exit() here, so this can't be run if exit
> +# is not working.
> +if [exit_is_reliable] {
> +    set test "continue with ignore count, not stopped at bpt"
> +    gdb_test_multiple "continue 2" "$test" {
> +	-re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
> +	    pass "$test"
> +	}
> +	-re "No breakpoint number -1.*$gdb_prompt $" {
> +	    kfail gdb/1689 "$test"
> +	}
>       }
>   }
>   
> diff --git a/gdb/testsuite/gdb.base/hook-stop.exp b/gdb/testsuite/gdb.base/hook-stop.exp
> index 6b49e39b7380..c9bc3d3b6438 100644
> --- a/gdb/testsuite/gdb.base/hook-stop.exp
> +++ b/gdb/testsuite/gdb.base/hook-stop.exp
> @@ -165,5 +165,15 @@ proc hook_stop_next {} {
>   hook_stop_before_frame
>   hook_stop_kill
>   hook_stop_continue_fg
> -hook_stop_continue_bg
> +
> +# Tests that run in background will not run properly with targets that
> +# doesn't have a proper "exit" function. For example, this particular
> +# test expects that after hook will resume inferior in background, there
> +# would be a message "exited normally", however such a message will
> +# appear only for targets with a proper # exit(), while others will, for
> +# example, spin in the infinite loop.
> +if [exit_is_reliable] {
> +    hook_stop_continue_bg
> +}
> +
>   hook_stop_next
> diff --git a/gdb/testsuite/gdb.base/nextoverexit.exp b/gdb/testsuite/gdb.base/nextoverexit.exp
> index 30eafef675ff..fcea35762b00 100644
> --- a/gdb/testsuite/gdb.base/nextoverexit.exp
> +++ b/gdb/testsuite/gdb.base/nextoverexit.exp
> @@ -14,6 +14,13 @@
>   
>   standard_testfile
>   
> +# This tests expects message "inferior exited normally", which is present only
> +# when exit() actually halts the target.
> +if ![exit_is_reliable] {
> +    unsupported "Function exit() is not reliable on this board."
> +    return 0
> +}
> +
>   if {[prepare_for_testing "failed to prepare" $testfile $testfile.c]} {
>       return -1
>   }
> diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp
> index 1149bb34c8dc..acec246f52ee 100644
> --- a/gdb/testsuite/gdb.mi/mi-break.exp
> +++ b/gdb/testsuite/gdb.mi/mi-break.exp
> @@ -244,6 +244,11 @@ proc test_disabled_creation {} {
>   proc test_breakpoint_commands {} {
>       global line_callee2_body
>   
> +    if ![exit_is_reliable] {
> +	unsupported "This test requires working exit() function."
> +	return 0
> +    }
> +
>       set bp_no_script \
>   	[mi_create_breakpoint "basics.c:callee2" \
>   	     "breakpoint commands: insert breakpoint at basics.c:callee2" \
> diff --git a/gdb/testsuite/gdb.mi/mi-exit-code.exp b/gdb/testsuite/gdb.mi/mi-exit-code.exp
> index f10b49cee0f8..fb5c693597da 100644
> --- a/gdb/testsuite/gdb.mi/mi-exit-code.exp
> +++ b/gdb/testsuite/gdb.mi/mi-exit-code.exp
> @@ -23,6 +23,11 @@ if [mi_gdb_start] {
>   
>   standard_testfile
>   
> +if ![exit_is_reliable] {
> +    unsupported "Function exit() is not reliable on this board."
> +    return 0
> +}
> +
>   if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
>       untested "failed to compile"
>       return -1
> diff --git a/gdb/testsuite/gdb.mi/mi-simplerun.exp b/gdb/testsuite/gdb.mi/mi-simplerun.exp
> index 20a079ead896..ce19122803da 100644
> --- a/gdb/testsuite/gdb.mi/mi-simplerun.exp
> +++ b/gdb/testsuite/gdb.mi/mi-simplerun.exp
> @@ -177,6 +177,11 @@ proc test_program_termination {} {
>       # -exec-abort
>       # (normal termination of inferior)
>   
> +    if ![exit_is_reliable] {
> +	unsupported "Function exit() is not reliable on this board."
> +	return
> +    }
> +
>       mi_execute_to "exec-continue" "exited-normally" "" "" "" "" "" "continue to end"
>   }
>   
> 

Re: [PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is unreliable

[Shahab Vahedi]

On 2/11/20 9:10 AM, Luis Machado wrote:
> Hi,
> 
> On 2/7/20 11:59 AM, Shahab Vahedi wrote:
>> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
>>
>> Tests that run in background will not run properly with targets that
>> doesn't have a proper "exit" function. For example, gdb.base/hook-stop
>> expects that after hook will resume inferior in background, there would
>> be a message "exited normally", however such a message will appear only
>> for targets with a proper exit(), while others will, for example, spin
>> in the infinite loop.
>>
>> Test gdb.base/nextoverexit expects message "inferior exited normally",
>> which is present only when exit() actually halts the target.
>>
>> Some tests in gdb.base/commands.exp has a flow that expects that
>> application can exit itself, which is not true when exit() function is
>> not reliable.
>>
>> This patch makes those tests conditional - they run only if exit is
>> reliable.
> 
> I don't know about this one. Doesn't your debugging stub have a way of detecting a call to exit, for example?

There is some testglue (gdb_tg.o) that prints to stdout if exit has happened with values other than 0. However, I believe the issue here is about running on a board. Anton is the best for responding to this.

> 
> These changes seem to indicate you are using some custom/modified dejagnu board to run your tests. Is your target a qemu/probe that gdb connects to and then does the tests?
That is correct. The target has never been qemu/probe. I believe it has been the in-house simulator and also some real boards.

> 
>>
>> gdb/testsuite/ChangeLog:
>> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>
>>
>>     * gdb.base/callexit.exp: Expect an "exit()" only if
>>     "exit_is_reliable" says so.
>>     * gdb.base/commands.exp: Likewise.
>>     * gdb.base/ena-dis-br.exp: Likewise.
>>     * gdb.base/hook-stop.exp: Likewise.
>>     * gdb.base/nextoverexit.exp: Likewise.
>>     * gdb.mi/mi-break.exp: Likewise.
>>     * gdb.mi/mi-exit-code.exp: Likewise.
>>     * gdb.mi/mi-simplerun.exp: Likewise.
>>
>> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
>> ---
>>   gdb/testsuite/gdb.base/callexit.exp     |  7 +++++++
>>   gdb/testsuite/gdb.base/commands.exp     | 14 ++++++++++++++
>>   gdb/testsuite/gdb.base/ena-dis-br.exp   | 18 +++++++++++-------
>>   gdb/testsuite/gdb.base/hook-stop.exp    | 12 +++++++++++-
>>   gdb/testsuite/gdb.base/nextoverexit.exp |  7 +++++++
>>   gdb/testsuite/gdb.mi/mi-break.exp       |  5 +++++
>>   gdb/testsuite/gdb.mi/mi-exit-code.exp   |  5 +++++
>>   gdb/testsuite/gdb.mi/mi-simplerun.exp   |  5 +++++
>>   8 files changed, 65 insertions(+), 8 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/callexit.exp b/gdb/testsuite/gdb.base/callexit.exp
>> index 67ff48283646..4fc2d5a2669a 100644
>> --- a/gdb/testsuite/gdb.base/callexit.exp
>> +++ b/gdb/testsuite/gdb.base/callexit.exp
>> @@ -28,6 +28,13 @@ if [target_info exists gdb,cannot_call_functions] {
>>       continue
>>   }
>>   +# Some targets (for example baremetal ones) doesn't have exit() that actually
>> +# exits anywhere.
>> +if ![exit_is_reliable] {
>> +    unsupported "This target doesn't have reliable exit() function."
>> +    continue
>> +}
>> +
>>   # Start with a fresh gdb.
>>     clean_restart ${binfile}
>> diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
>> index 869d0a81a4a7..fd92b3fa3111 100644
>> --- a/gdb/testsuite/gdb.base/commands.exp
>> +++ b/gdb/testsuite/gdb.base/commands.exp
>> @@ -694,6 +694,13 @@ proc_with_prefix deprecated_command_test {} {
>>   proc_with_prefix bp_deleted_in_command_test {} {
>>       global gdb_prompt
>>   +    # Flow of this test assumes that application will halt after reaching the
>> +    # exit() function.
>> +    if ![exit_is_reliable] {
>> +    unsupported "Function exit() is not reliable on this board."
>> +    return 0
>> +    }
>> +
>>       delete_breakpoints
>>         # Create a breakpoint, and associate a command-list to it, with
>> @@ -736,6 +743,13 @@ proc_with_prefix bp_deleted_in_command_test {} {
>>   }
>>     proc_with_prefix temporary_breakpoint_commands {} {
>> +    # Flow of this test assumes that application will halt after reaching the
>> +    # exit() function.
>> +    if ![exit_is_reliable] {
>> +    unsupported "Function exit() is not reliable on this board."
>> +    return 0
>> +    }
>> +
>>       delete_breakpoints
>>         # Create a temporary breakpoint, and associate a commands list to it.
>> diff --git a/gdb/testsuite/gdb.base/ena-dis-br.exp b/gdb/testsuite/gdb.base/ena-dis-br.exp
>> index c338a0d51fa9..bf670cbae948 100644
>> --- a/gdb/testsuite/gdb.base/ena-dis-br.exp
>> +++ b/gdb/testsuite/gdb.base/ena-dis-br.exp
>> @@ -295,13 +295,17 @@ gdb_test "continue 2" \
>>   gdb_test "next" ".*$bp_location11\[ \t\]*marker1.*" \
>>       "step after continue with ignore count"
>>   -set test "continue with ignore count, not stopped at bpt"
>> -gdb_test_multiple "continue 2" "$test" {
>> -    -re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
>> -    pass "$test"
>> -    }
>> -    -re "No breakpoint number -1.*$gdb_prompt $" {
>> -    kfail gdb/1689 "$test"
>> +# Application is expected to reach an exit() here, so this can't be run if exit
>> +# is not working.
>> +if [exit_is_reliable] {
>> +    set test "continue with ignore count, not stopped at bpt"
>> +    gdb_test_multiple "continue 2" "$test" {
>> +    -re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
>> +        pass "$test"
>> +    }
>> +    -re "No breakpoint number -1.*$gdb_prompt $" {
>> +        kfail gdb/1689 "$test"
>> +    }
>>       }
>>   }
>>   diff --git a/gdb/testsuite/gdb.base/hook-stop.exp b/gdb/testsuite/gdb.base/hook-stop.exp
>> index 6b49e39b7380..c9bc3d3b6438 100644
>> --- a/gdb/testsuite/gdb.base/hook-stop.exp
>> +++ b/gdb/testsuite/gdb.base/hook-stop.exp
>> @@ -165,5 +165,15 @@ proc hook_stop_next {} {
>>   hook_stop_before_frame
>>   hook_stop_kill
>>   hook_stop_continue_fg
>> -hook_stop_continue_bg
>> +
>> +# Tests that run in background will not run properly with targets that
>> +# doesn't have a proper "exit" function. For example, this particular
>> +# test expects that after hook will resume inferior in background, there
>> +# would be a message "exited normally", however such a message will
>> +# appear only for targets with a proper # exit(), while others will, for
>> +# example, spin in the infinite loop.
>> +if [exit_is_reliable] {
>> +    hook_stop_continue_bg
>> +}
>> +
>>   hook_stop_next
>> diff --git a/gdb/testsuite/gdb.base/nextoverexit.exp b/gdb/testsuite/gdb.base/nextoverexit.exp
>> index 30eafef675ff..fcea35762b00 100644
>> --- a/gdb/testsuite/gdb.base/nextoverexit.exp
>> +++ b/gdb/testsuite/gdb.base/nextoverexit.exp
>> @@ -14,6 +14,13 @@
>>     standard_testfile
>>   +# This tests expects message "inferior exited normally", which is present only
>> +# when exit() actually halts the target.
>> +if ![exit_is_reliable] {
>> +    unsupported "Function exit() is not reliable on this board."
>> +    return 0
>> +}
>> +
>>   if {[prepare_for_testing "failed to prepare" $testfile $testfile.c]} {
>>       return -1
>>   }
>> diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp
>> index 1149bb34c8dc..acec246f52ee 100644
>> --- a/gdb/testsuite/gdb.mi/mi-break.exp
>> +++ b/gdb/testsuite/gdb.mi/mi-break.exp
>> @@ -244,6 +244,11 @@ proc test_disabled_creation {} {
>>   proc test_breakpoint_commands {} {
>>       global line_callee2_body
>>   +    if ![exit_is_reliable] {
>> +    unsupported "This test requires working exit() function."
>> +    return 0
>> +    }
>> +
>>       set bp_no_script \
>>       [mi_create_breakpoint "basics.c:callee2" \
>>            "breakpoint commands: insert breakpoint at basics.c:callee2" \
>> diff --git a/gdb/testsuite/gdb.mi/mi-exit-code.exp b/gdb/testsuite/gdb.mi/mi-exit-code.exp
>> index f10b49cee0f8..fb5c693597da 100644
>> --- a/gdb/testsuite/gdb.mi/mi-exit-code.exp
>> +++ b/gdb/testsuite/gdb.mi/mi-exit-code.exp
>> @@ -23,6 +23,11 @@ if [mi_gdb_start] {
>>     standard_testfile
>>   +if ![exit_is_reliable] {
>> +    unsupported "Function exit() is not reliable on this board."
>> +    return 0
>> +}
>> +
>>   if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
>>       untested "failed to compile"
>>       return -1
>> diff --git a/gdb/testsuite/gdb.mi/mi-simplerun.exp b/gdb/testsuite/gdb.mi/mi-simplerun.exp
>> index 20a079ead896..ce19122803da 100644
>> --- a/gdb/testsuite/gdb.mi/mi-simplerun.exp
>> +++ b/gdb/testsuite/gdb.mi/mi-simplerun.exp
>> @@ -177,6 +177,11 @@ proc test_program_termination {} {
>>       # -exec-abort
>>       # (normal termination of inferior)
>>   +    if ![exit_is_reliable] {
>> +    unsupported "Function exit() is not reliable on this board."
>> +    return
>> +    }
>> +
>>       mi_execute_to "exec-continue" "exited-normally" "" "" "" "" "" "continue to end"
>>   }
>>  

RE: [PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is unreliable

[Anton Kolesov]

> -----Original Message-----
> From: Shahab Vahedi
> Sent: Tuesday, February 18, 2020 18:42
> To: Luis Machado <luis.machado@linaro.org>; Shahab Vahedi
> <shahab.vahedi@gmail.com>; gdb-patches@sourceware.org
> Cc: Francois Bedard <fbedard@synopsys.com>; Anton Kolesov
> <akolesov@synopsys.com>
> Subject: Re: [PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is
> unreliable
> 
> On 2/11/20 9:10 AM, Luis Machado wrote:
> > Hi,
> >
> > On 2/7/20 11:59 AM, Shahab Vahedi wrote:
> >> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> >>
> >>
> >> This patch makes those tests conditional - they run only if exit is
> >> reliable.
> >
> > I don't know about this one. Doesn't your debugging stub have a way of
> detecting a call to exit, for example?
> 
> There is some testglue (gdb_tg.o) that prints to stdout if exit has happened
> with values other than 0. However, I believe the issue here is about running on
> a board. Anton is the best for responding to this.

ARC gdb-servers don't detect call to exit - they are mostly "dumb" stubs that
defer to GDB client to do the application-level work, or in this case it is
testsuite's job to detect that _exit has been called. In general test suite
handle this properly - it sets breakpoint at _exit call and treats first
argument to invocation as exit code, however certain test cases expect
application to really exit, and IIRC the purpose of this patch is to skip
those test on a baremetal target - we'd need a semihosting library or equivalent,
and that is not fully supported in ARC gdbservers - or better to say it is not
supported at all in most of them.

> 
> >
> > These changes seem to indicate you are using some custom/modified
> dejagnu board to run your tests. Is your target a qemu/probe that gdb
> connects to and then does the tests?
> That is correct. The target has never been qemu/probe. I believe it has been
> the in-house simulator and also some real boards.

I've used proprietary simulator with built-in GDB-server and OpenOCD. There is
also support for ARC in other GDB-servers developed by Synopsys and
3rd-parties, each being a distinct implementation. Board files can be found at 
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-releases/dejagnu/baseboards/arc-nsim.exp
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-releases/dejagnu/baseboards/arc-openocd.exp
and their dependencies are in the same GitHub repository.

Re: [PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is unreliable

[Andrew Burgess]

* Shahab Vahedi <shahab.vahedi@gmail.com> [2020-02-07 15:59:53 +0100]:

> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Tests that run in background will not run properly with targets that
> doesn't have a proper "exit" function. For example, gdb.base/hook-stop
> expects that after hook will resume inferior in background, there would
> be a message "exited normally", however such a message will appear only
> for targets with a proper exit(), while others will, for example, spin
> in the infinite loop.
> 
> Test gdb.base/nextoverexit expects message "inferior exited normally",
> which is present only when exit() actually halts the target.
> 
> Some tests in gdb.base/commands.exp has a flow that expects that
> application can exit itself, which is not true when exit() function is
> not reliable.
> 
> This patch makes those tests conditional - they run only if exit is
> reliable.
> 
> gdb/testsuite/ChangeLog:
> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/callexit.exp: Expect an "exit()" only if
> 	"exit_is_reliable" says so.
> 	* gdb.base/commands.exp: Likewise.
> 	* gdb.base/ena-dis-br.exp: Likewise.
> 	* gdb.base/hook-stop.exp: Likewise.
> 	* gdb.base/nextoverexit.exp: Likewise.
> 	* gdb.mi/mi-break.exp: Likewise.
> 	* gdb.mi/mi-exit-code.exp: Likewise.
> 	* gdb.mi/mi-simplerun.exp: Likewise.
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>  gdb/testsuite/gdb.base/callexit.exp     |  7 +++++++
>  gdb/testsuite/gdb.base/commands.exp     | 14 ++++++++++++++
>  gdb/testsuite/gdb.base/ena-dis-br.exp   | 18 +++++++++++-------
>  gdb/testsuite/gdb.base/hook-stop.exp    | 12 +++++++++++-
>  gdb/testsuite/gdb.base/nextoverexit.exp |  7 +++++++
>  gdb/testsuite/gdb.mi/mi-break.exp       |  5 +++++
>  gdb/testsuite/gdb.mi/mi-exit-code.exp   |  5 +++++
>  gdb/testsuite/gdb.mi/mi-simplerun.exp   |  5 +++++
>  8 files changed, 65 insertions(+), 8 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/callexit.exp b/gdb/testsuite/gdb.base/callexit.exp
> index 67ff48283646..4fc2d5a2669a 100644
> --- a/gdb/testsuite/gdb.base/callexit.exp
> +++ b/gdb/testsuite/gdb.base/callexit.exp
> @@ -28,6 +28,13 @@ if [target_info exists gdb,cannot_call_functions] {
>      continue
>  }
>  
> +# Some targets (for example baremetal ones) doesn't have exit() that actually
> +# exits anywhere.
> +if ![exit_is_reliable] {
> +    unsupported "This target doesn't have reliable exit() function."
> +    continue
> +}

When the `if' check is at the top level I think you'd be better off
dropping the comment as the code is pretty self-explanatory, maybe
you'd be better putting more detail onto the comment on
'exit_is_reliable' itself.  I think this applies to every case where
the comment just says, 'if exit is not reliable, don't run this test'
as I think that's obvious from the code, if there's cases where more
detail is required then by all means, keep the comments.

Also the message in 'unsupported' shouldn't start with a capital
letter.

> +
>  # Start with a fresh gdb.
>  
>  clean_restart ${binfile}
> diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
> index 869d0a81a4a7..fd92b3fa3111 100644
> --- a/gdb/testsuite/gdb.base/commands.exp
> +++ b/gdb/testsuite/gdb.base/commands.exp
> @@ -694,6 +694,13 @@ proc_with_prefix deprecated_command_test {} {
>  proc_with_prefix bp_deleted_in_command_test {} {
>      global gdb_prompt
>  
> +    # Flow of this test assumes that application will halt after reaching the
> +    # exit() function.
> +    if ![exit_is_reliable] {
> +	unsupported "Function exit() is not reliable on this board."
> +	return 0
> +    }
> +
>      delete_breakpoints
>  
>      # Create a breakpoint, and associate a command-list to it, with
> @@ -736,6 +743,13 @@ proc_with_prefix bp_deleted_in_command_test {} {
>  }
>  
>  proc_with_prefix temporary_breakpoint_commands {} {
> +    # Flow of this test assumes that application will halt after reaching the
> +    # exit() function.
> +    if ![exit_is_reliable] {
> +	unsupported "Function exit() is not reliable on this board."
> +	return 0
> +    }
> +
>      delete_breakpoints
>  
>      # Create a temporary breakpoint, and associate a commands list to it.
> diff --git a/gdb/testsuite/gdb.base/ena-dis-br.exp b/gdb/testsuite/gdb.base/ena-dis-br.exp
> index c338a0d51fa9..bf670cbae948 100644
> --- a/gdb/testsuite/gdb.base/ena-dis-br.exp
> +++ b/gdb/testsuite/gdb.base/ena-dis-br.exp
> @@ -295,13 +295,17 @@ gdb_test "continue 2" \
>  gdb_test "next" ".*$bp_location11\[ \t\]*marker1.*" \
>      "step after continue with ignore count"
>  
> -set test "continue with ignore count, not stopped at bpt"
> -gdb_test_multiple "continue 2" "$test" {
> -    -re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
> -	pass "$test"
> -    }
> -    -re "No breakpoint number -1.*$gdb_prompt $" {
> -	kfail gdb/1689 "$test"
> +# Application is expected to reach an exit() here, so this can't be run if exit
> +# is not working.
> +if [exit_is_reliable] {
> +    set test "continue with ignore count, not stopped at bpt"
> +    gdb_test_multiple "continue 2" "$test" {
> +	-re "Not stopped at any breakpoint; argument ignored.*$gdb_prompt $" {
> +	    pass "$test"
> +	}
> +	-re "No breakpoint number -1.*$gdb_prompt $" {
> +	    kfail gdb/1689 "$test"
> +	}
>      }
>  }
>  
> diff --git a/gdb/testsuite/gdb.base/hook-stop.exp b/gdb/testsuite/gdb.base/hook-stop.exp
> index 6b49e39b7380..c9bc3d3b6438 100644
> --- a/gdb/testsuite/gdb.base/hook-stop.exp
> +++ b/gdb/testsuite/gdb.base/hook-stop.exp
> @@ -165,5 +165,15 @@ proc hook_stop_next {} {
>  hook_stop_before_frame
>  hook_stop_kill
>  hook_stop_continue_fg
> -hook_stop_continue_bg
> +
> +# Tests that run in background will not run properly with targets that
> +# doesn't have a proper "exit" function. For example, this particular
> +# test expects that after hook will resume inferior in background, there
> +# would be a message "exited normally", however such a message will
> +# appear only for targets with a proper # exit(), while others will, for
> +# example, spin in the infinite loop.

I found this comment pretty confused, how about:

  # Tests that run in background will not run properly with targets
  # that doesn't have a proper "exit" function.  This test expects
  # that the after hook will resume the inferior in the background,
  # after which there would be a message "inferior exited normally".
  # Such a message will appear only for targets with a proper exit()
  # function, if the target simply spins in a loop instead of exiting
  # then the message will never appear.

What wasn't clear to me when I thought about this though was what does
your target actually do in this case?  You say in another mail that
your board file places a breakpoint on _exit and extracts the return
value from there - is that true for the GDB tests too?  Doesn't that
mean you actually hit the breakpoint in this case?

I'm not suggesting we should change the test to expect a breakpoint
hit, I'm more curious...

Thanks,
Andrew

> +if [exit_is_reliable] {
> +    hook_stop_continue_bg
> +}
> +
>  hook_stop_next
> diff --git a/gdb/testsuite/gdb.base/nextoverexit.exp b/gdb/testsuite/gdb.base/nextoverexit.exp
> index 30eafef675ff..fcea35762b00 100644
> --- a/gdb/testsuite/gdb.base/nextoverexit.exp
> +++ b/gdb/testsuite/gdb.base/nextoverexit.exp
> @@ -14,6 +14,13 @@
>  
>  standard_testfile
>  
> +# This tests expects message "inferior exited normally", which is present only
> +# when exit() actually halts the target.
> +if ![exit_is_reliable] {
> +    unsupported "Function exit() is not reliable on this board."
> +    return 0
> +}
> +
>  if {[prepare_for_testing "failed to prepare" $testfile $testfile.c]} {
>      return -1
>  }
> diff --git a/gdb/testsuite/gdb.mi/mi-break.exp b/gdb/testsuite/gdb.mi/mi-break.exp
> index 1149bb34c8dc..acec246f52ee 100644
> --- a/gdb/testsuite/gdb.mi/mi-break.exp
> +++ b/gdb/testsuite/gdb.mi/mi-break.exp
> @@ -244,6 +244,11 @@ proc test_disabled_creation {} {
>  proc test_breakpoint_commands {} {
>      global line_callee2_body
>  
> +    if ![exit_is_reliable] {
> +	unsupported "This test requires working exit() function."
> +	return 0
> +    }
> +
>      set bp_no_script \
>  	[mi_create_breakpoint "basics.c:callee2" \
>  	     "breakpoint commands: insert breakpoint at basics.c:callee2" \
> diff --git a/gdb/testsuite/gdb.mi/mi-exit-code.exp b/gdb/testsuite/gdb.mi/mi-exit-code.exp
> index f10b49cee0f8..fb5c693597da 100644
> --- a/gdb/testsuite/gdb.mi/mi-exit-code.exp
> +++ b/gdb/testsuite/gdb.mi/mi-exit-code.exp
> @@ -23,6 +23,11 @@ if [mi_gdb_start] {
>  
>  standard_testfile
>  
> +if ![exit_is_reliable] {
> +    unsupported "Function exit() is not reliable on this board."
> +    return 0
> +}
> +
>  if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
>      untested "failed to compile"
>      return -1
> diff --git a/gdb/testsuite/gdb.mi/mi-simplerun.exp b/gdb/testsuite/gdb.mi/mi-simplerun.exp
> index 20a079ead896..ce19122803da 100644
> --- a/gdb/testsuite/gdb.mi/mi-simplerun.exp
> +++ b/gdb/testsuite/gdb.mi/mi-simplerun.exp
> @@ -177,6 +177,11 @@ proc test_program_termination {} {
>      # -exec-abort
>      # (normal termination of inferior)
>  
> +    if ![exit_is_reliable] {
> +	unsupported "Function exit() is not reliable on this board."
> +	return
> +    }
> +
>      mi_execute_to "exec-continue" "exited-normally" "" "" "" "" "" "continue to end"
>  }
>  
> -- 
> 2.25.0
> 

[PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test

[Shahab Vahedi]

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

Fileio test improperly checks if [is_remote host] and if it is, then
uses file path that is safe to use on remote host.  But the problem is
that [is_remote host] returns state of *this* host, not of the remote
target, where filepaths actually matter.  This patch fixes that.

gdb/testsuite/ChangeLog:
2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.base/fileio.exp: Use "target" instead of "host".

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/fileio.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
index 9735869e5190..627a685e118d 100644
--- a/gdb/testsuite/gdb.base/fileio.exp
+++ b/gdb/testsuite/gdb.base/fileio.exp
@@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] {
 
 standard_testfile
 
-if {[is_remote host]} {
+if {[is_remote target]} {
     set outdir .
 } else {
     set outdir [standard_output_file {}]
-- 
2.25.0

Re: [PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test

[Luis Machado]

Hi,

On 2/7/20 11:59 AM, Shahab Vahedi wrote:
> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Fileio test improperly checks if [is_remote host] and if it is, then
> uses file path that is safe to use on remote host.  But the problem is
> that [is_remote host] returns state of *this* host, not of the remote
> target, where filepaths actually matter.  This patch fixes that.

Do you remember what that error was? I don't see any errors running on 
my end. Though the patch doesn't introduce new errors as well.

Were you using a different board file that exercised gdbserver running 
on a remote host?

I'm trying to understand what the problem is.

> 
> gdb/testsuite/ChangeLog:
> 2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/fileio.exp: Use "target" instead of "host".
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>   gdb/testsuite/gdb.base/fileio.exp | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
> index 9735869e5190..627a685e118d 100644
> --- a/gdb/testsuite/gdb.base/fileio.exp
> +++ b/gdb/testsuite/gdb.base/fileio.exp
> @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] {
>   
>   standard_testfile
>   
> -if {[is_remote host]} {
> +if {[is_remote target]} {
>       set outdir .
>   } else {
>       set outdir [standard_output_file {}]
> 

Re: [PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test

[Shahab Vahedi]

On 2/11/20 8:29 AM, Luis Machado wrote:
> Hi,
> 
> On 2/7/20 11:59 AM, Shahab Vahedi wrote:
>> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
>>
>> Fileio test improperly checks if [is_remote host] and if it is, then
>> uses file path that is safe to use on remote host.  But the problem is
>> that [is_remote host] returns state of *this* host, not of the remote
>> target, where filepaths actually matter.  This patch fixes that.
> 
> Do you remember what that error was? I don't see any errors running on my end. Though the patch doesn't introduce new errors as well.
> 
> Were you using a different board file that exercised gdbserver running on a remote host?

Indeed specific boards for ARC are used. And yes, there were/are 2 ways
that these boards were executed: through a simulator and on real boards
(remote hosts).

> 
> I'm trying to understand what the problem is.
> 
>>
>> gdb/testsuite/ChangeLog:
>> 2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>
>>
>>     * gdb.base/fileio.exp: Use "target" instead of "host".
>>
>> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
>> ---
>>   gdb/testsuite/gdb.base/fileio.exp | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
>> index 9735869e5190..627a685e118d 100644
>> --- a/gdb/testsuite/gdb.base/fileio.exp
>> +++ b/gdb/testsuite/gdb.base/fileio.exp
>> @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] {
>>     standard_testfile
>>   -if {[is_remote host]} {
>> +if {[is_remote target]} {
>>       set outdir .
>>   } else {
>>       set outdir [standard_output_file {}]
>>

Re: [PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test

[Andrew Burgess]

* Shahab Vahedi <shahab.vahedi@gmail.com> [2020-02-07 15:59:50 +0100]:

> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Fileio test improperly checks if [is_remote host] and if it is, then
> uses file path that is safe to use on remote host.  But the problem is
> that [is_remote host] returns state of *this* host, not of the remote
> target, where filepaths actually matter.  This patch fixes that.
> 
> gdb/testsuite/ChangeLog:
> 2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/fileio.exp: Use "target" instead of "host".
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>

I don't really understand what the problem is here.

I'm probably just not understanding things, so please, correct let me
know where I'm going wrong, but I thought..

'is_remote host' - when this is true we're running dejagnu on machine
A, but actually running GDB on machine B.  GDB might then be talking
to a remote target on machine C, or maybe the test is also running on
machine B.

'is_remote target' - when this is true the thing being debugged is not
a child of the GDB process, it could be on a different machine, or it
could be gdbserver on the same machine, but it still seems to be
"remote" as far as GDB is concerned.

The fileio.exp test is I think testing remote fileio, not native
fileio, so when the test tries to open a file, it will be GDB that
actually opens the file for us.

So, if 'is_remote host' is false, then the files we open should be in
the local dejagnu file system, with the longer paths, while if
'is_remote host' is true, then I think the assumption is that GDB will
have been pushed over from the local tree to the remote host, and we
don't have the full file system hierarchy, so lets just use '.' as a
path prefix.

I don't think this test really makes much sense when 'is_remote
target' is false, otherwise we're just testing, what? That GDB doesn't
prevent the target doing IO?  And once upon a time we indeed made this
check, see commit 1bcdb42447a4a68d7c3837b3852db3fb632e379b, but this
was quickly changed in b257a0d30ab67df224f603c928127f2e653660b9 to a
check based on the target properties.

If I was going to guess, I'd guess your target can do real IO, into a
local file system?  I think, if this is the case you should be setting
'set_board_info gdb,nofileio 1' in your board file - but like I say,
this is just a guess.

Thanks,
Andrew



> ---
>  gdb/testsuite/gdb.base/fileio.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
> index 9735869e5190..627a685e118d 100644
> --- a/gdb/testsuite/gdb.base/fileio.exp
> +++ b/gdb/testsuite/gdb.base/fileio.exp
> @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] {
>  
>  standard_testfile
>  
> -if {[is_remote host]} {
> +if {[is_remote target]} {
>      set outdir .
>  } else {
>      set outdir [standard_output_file {}]
> -- 
> 2.25.0
> 

[PATCH 13/14] gdb/testsuite: Skip killed-outside when nosignals

[Shahab Vahedi]

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

Test "killed-outside.exp" uses "kill -9" to kill target process via PID,
something that will never work with an emdedded target has neither PID, nor is
accessible to the host "kill" utility. Skip this test if "gdb,nosignals" is
set.

gdb/testsuite/ChangeLog:
2016-08-18  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.base/killed-outside.exp: Skip the test if there is
	"nosignal".

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/killed-outside.exp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/testsuite/gdb.base/killed-outside.exp b/gdb/testsuite/gdb.base/killed-outside.exp
index 3e20ad67ceee..abb63e1512d6 100644
--- a/gdb/testsuite/gdb.base/killed-outside.exp
+++ b/gdb/testsuite/gdb.base/killed-outside.exp
@@ -80,6 +80,11 @@ proc test {cmds_after_kill} {
     }
 }
 
+if [target_info exists gdb,nosignals] {
+    verbose "Skipping killed-outside.exp because of nosignals."
+    continue
+}
+
 if {[prepare_for_testing "failed to prepare" $testfile $srcfile] == -1} {
     return -1
 }
-- 
2.25.0

[PATCH 08/14] gdb/testsuite: Fix bug in break-unload-file

[Shahab Vahedi]

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

Test cases should call prepare_for_testing instead of build_executable,
otherwise path to current executable will be unchanged - set to the one
left from the previous testcase.

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

	* gdb.base/break-unload-file.exp: Use "prepare_for_testing"
	instead of "build_executable".

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/break-unload-file.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/break-unload-file.exp b/gdb/testsuite/gdb.base/break-unload-file.exp
index f59e727dbca4..ac26b8694bf2 100644
--- a/gdb/testsuite/gdb.base/break-unload-file.exp
+++ b/gdb/testsuite/gdb.base/break-unload-file.exp
@@ -18,7 +18,7 @@
 
 standard_testfile
 
-if {[build_executable "failed to prepare" $testfile $srcfile debug]} {
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile debug]} {
     return -1
 }
 
-- 
2.25.0

[PATCH 12/14] gdb/testsuite: Skip on of the interp.exp test for remote targets

[Shahab Vahedi]

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

One of the tests in interp.exp invokes `-stack-info-frame` through MI and
expects that it will return "no registers", because application is not being
run. However, if this is done with gdbserver, then GDB is already connected to
the server, therefore registers actually exist and the test fails.

gdb/testsuite/ChangeLog:
2016-08-19  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.base/interp.exp: Skip "stack-info-frame" test
	if gdbserver was used.

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

diff --git a/gdb/testsuite/gdb.base/interp.exp b/gdb/testsuite/gdb.base/interp.exp
index d2a6d42732e8..2e1e9901e952 100644
--- a/gdb/testsuite/gdb.base/interp.exp
+++ b/gdb/testsuite/gdb.base/interp.exp
@@ -44,14 +44,18 @@ gdb_test_multiple "interpreter-exec mi \"-break-insert --thread a\"" \
 	}
     }
 
-set cmd "interpreter-exec mi \"-stack-info-frame\""
-gdb_test_multiple $cmd $cmd {
-    -re ".error,msg=.No registers\..\r\n$gdb_prompt " {
-	pass "$cmd"
-	gdb_expect 1 {
-	    -re "\r\n$gdb_prompt $" { }
-	}
-    }
+# If this is a remote target, then GDB already connected to the server, so
+# registers do exist and this test doesn't make sense.
+if !$use_gdb_stub {
+  set cmd "interpreter-exec mi \"-stack-info-frame\""
+  gdb_test_multiple $cmd $cmd {
+      -re ".error,msg=.No registers\..\r\n$gdb_prompt " {
+	  pass "$cmd"
+	  gdb_expect 1 {
+	      -re "\r\n$gdb_prompt $" { }
+	  }
+      }
+  }
 }
 
 set cmd "interpreter-exec mi1 \"-break-insert main\""
-- 
2.25.0

[PATCH 10/14] gdb/testsuite: Fix gdb.base/chng-syms.exp for remote target

[Shahab Vahedi]

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

The pattern with which proc "gdb_load" in config/monitor.exp catches
errors during application load is not always appropriate - it assumes
that any message with the word "failed" in it means a load failure,
which is not correct. For example, testcase gdb.base/chng-syms.exp
causes a message: "warning: failed to reevaluate condition for
breakpoint 1" which is an expected result and doesn't mean that load
itself failed.

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

	* config/monitor.exp (gdb_load): Handle a false positive
	failure case.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/config/monitor.exp | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdb/testsuite/config/monitor.exp b/gdb/testsuite/config/monitor.exp
index 7e74dad100cc..f215ee4ea4c8 100644
--- a/gdb/testsuite/config/monitor.exp
+++ b/gdb/testsuite/config/monitor.exp
@@ -230,6 +230,14 @@ proc gdb_load { arg } {
 	    set load_ok 0
 	    send_gdb $command
 	    gdb_expect $loadtimeout {
+		-re "warning: failed to reevaluate condition" {
+		    # Catching just any "failed" word is not correct here. For
+		    # example, testcase gdb.base/chng-syms.exp causes a message:
+		    # "warning: failed to reevaluate condition for breakpoint 1"
+		    # which is an expected result and doesn't mean that load
+		    # itself failed.
+		    exp_continue
+		}
 		-re "\[Ff\]ailed.*$gdb_prompt $" {
 		    verbose "load failed"
 		}
-- 
2.25.0

[PATCH 14/14] gdb/testsuite: Skip some compile.exp tests when running with gdb-comm board

[Shahab Vahedi]

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

gdb/testsuite/ChangeLog:
2016-08-19  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.compile/compile.exp: Skip if "gdb_comm" was used.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.compile/compile.exp | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/gdb/testsuite/gdb.compile/compile.exp b/gdb/testsuite/gdb.compile/compile.exp
index 9ad4181b2fe8..eb4f9bae11dd 100644
--- a/gdb/testsuite/gdb.compile/compile.exp
+++ b/gdb/testsuite/gdb.compile/compile.exp
@@ -40,17 +40,20 @@ clean_restart ${testfile}
 #
 # Test command without an running inferior.
 #
-gdb_test "compile code int i=2;" \
-    "The program must be running for the compile command to work.*" \
-    "test compile code command without running inferior"
-
-gdb_test "compile int i=2;" \
-    "The program must be running for the compile command to work.*" \
-    "test compile command without running inferior"
-
-gdb_test "compile file -r ${srcdir}/${subdir}/${testfile}-mod.c" \
-    "The program must be running for the compile command to work.*" \
-    "test compile file command without running inferior"
+# If target is run via gdb_comm board, then there is already running inferior.
+if {[target_info protocol] != "gdb_comm"} {
+    gdb_test "compile code int i=2;" \
+	"The program must be running for the compile command to work.*" \
+	"test compile code command without running inferior"
+
+    gdb_test "compile int i=2;" \
+	"The program must be running for the compile command to work.*" \
+	"test compile command without running inferior"
+
+    gdb_test "compile file -r ${srcdir}/${subdir}/${testfile}-mod.c" \
+	"The program must be running for the compile command to work.*" \
+	"test compile file command without running inferior"
+}
 
 if ![runto_main] {
     return -1
-- 
2.25.0

[PATCH 03/14] gdb/testsuite: Add exit_is_reliable proc

[Shahab Vahedi]

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

Add a function that returns 1 if exit is reliable or 0 otherwise. Previously
value of "board_info gdb,exit_is_reliable" was used only in one place, in
"gdb_continue_to_end", and sensible default value was evaluated at the same
location. However there are more places that need to check value of
"gdb,exit_is_reliable", so it makes sense to extract it into a separate
function that returns a reliable value.

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

        * lib/gdb.exp (exit_is_reliable): Procedure is added.
        (gdb_continue_to_end): Refactor to use "exit_is_reliable".

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/lib/gdb.exp | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index eb1d145f2bb7..4376e08ca1b2 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3357,6 +3357,16 @@ proc use_gdb_stub {} {
   return [target_info exists use_gdb_stub]
 }
 
+# Return 1 if target has a reliable exit() function, 0 - otherwise.
+
+proc exit_is_reliable {} {
+    if { [target_info exists exit_is_reliable] } {
+      return [target_info exit_is_reliable]
+    } else {
+      return ![use_gdb_stub]
+    }
+}
+
 # Return 1 if the current remote target is an instance of our GDBserver, 0
 # otherwise.  Return -1 if there was an error and we can't tell.
 
@@ -5287,13 +5297,7 @@ proc gdb_continue_to_end {{mssg ""} {command continue} {allow_extra 0}} {
   # loop, or a forced crash/reset.  For native targets, by default, we
   # assume process exit is reported as such.  If a non-reliable target
   # is used, we set a breakpoint at exit, and continue to that.
-  if { [target_info exists exit_is_reliable] } {
-      set exit_is_reliable [target_info exit_is_reliable]
-  } else {
-      set exit_is_reliable [expr ! $use_gdb_stub]
-  }
-
-  if { ! $exit_is_reliable } {
+  if ![exit_is_reliable] {
     if {![gdb_breakpoint "exit"]} {
       return 0
     }
-- 
2.25.0

Re: [PATCH 03/14] gdb/testsuite: Add exit_is_reliable proc

[Luis Machado]

On 2/7/20 11:59 AM, Shahab Vahedi wrote:
> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Add a function that returns 1 if exit is reliable or 0 otherwise. Previously
> value of "board_info gdb,exit_is_reliable" was used only in one place, in
> "gdb_continue_to_end", and sensible default value was evaluated at the same
> location. However there are more places that need to check value of
> "gdb,exit_is_reliable", so it makes sense to extract it into a separate
> function that returns a reliable value.
> 
> gdb/testsuite/ChangeLog:
> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
>          * lib/gdb.exp (exit_is_reliable): Procedure is added.
>          (gdb_continue_to_end): Refactor to use "exit_is_reliable".
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>   gdb/testsuite/lib/gdb.exp | 18 +++++++++++-------
>   1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index eb1d145f2bb7..4376e08ca1b2 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3357,6 +3357,16 @@ proc use_gdb_stub {} {
>     return [target_info exists use_gdb_stub]
>   }
>   
> +# Return 1 if target has a reliable exit() function, 0 - otherwise.
> +
> +proc exit_is_reliable {} {
> +    if { [target_info exists exit_is_reliable] } {
> +      return [target_info exit_is_reliable]
> +    } else {
> +      return ![use_gdb_stub]
> +    }
> +}
> +
>   # Return 1 if the current remote target is an instance of our GDBserver, 0
>   # otherwise.  Return -1 if there was an error and we can't tell.
>   
> @@ -5287,13 +5297,7 @@ proc gdb_continue_to_end {{mssg ""} {command continue} {allow_extra 0}} {
>     # loop, or a forced crash/reset.  For native targets, by default, we
>     # assume process exit is reported as such.  If a non-reliable target
>     # is used, we set a breakpoint at exit, and continue to that.
> -  if { [target_info exists exit_is_reliable] } {
> -      set exit_is_reliable [target_info exit_is_reliable]
> -  } else {
> -      set exit_is_reliable [expr ! $use_gdb_stub]
> -  }
> -
> -  if { ! $exit_is_reliable } {
> +  if ![exit_is_reliable] {
>       if {![gdb_breakpoint "exit"]} {
>         return 0
>       }
> 

This LGTM as a refactor.

Re: [PATCH 03/14] gdb/testsuite: Add exit_is_reliable proc

[Andrew Burgess]

* Shahab Vahedi <shahab.vahedi@gmail.com> [2020-02-07 15:59:52 +0100]:

> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Add a function that returns 1 if exit is reliable or 0 otherwise. Previously
> value of "board_info gdb,exit_is_reliable" was used only in one place, in
> "gdb_continue_to_end", and sensible default value was evaluated at the same
> location. However there are more places that need to check value of
> "gdb,exit_is_reliable", so it makes sense to extract it into a separate
> function that returns a reliable value.
> 
> gdb/testsuite/ChangeLog:
> 2016-07-13  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
>         * lib/gdb.exp (exit_is_reliable): Procedure is added.
>         (gdb_continue_to_end): Refactor to use "exit_is_reliable".

This is fine in theory, but...

> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>  gdb/testsuite/lib/gdb.exp | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index eb1d145f2bb7..4376e08ca1b2 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -3357,6 +3357,16 @@ proc use_gdb_stub {} {
>    return [target_info exists use_gdb_stub]
>  }
>  
> +# Return 1 if target has a reliable exit() function, 0 - otherwise.
> +
> +proc exit_is_reliable {} {
> +    if { [target_info exists exit_is_reliable] } {
> +      return [target_info exit_is_reliable]
> +    } else {
> +      return ![use_gdb_stub]
> +    }
> +}

I don't see how the header comment on this proc matches that
implementation.  Maybe a comment more like this:

  Return non-zero if target has a reliable exit() function or if the
  target is not using the gdb stub (see USE_GDB_STUB).  Otherwise
  return false.

But otherwise seems like a reasonable clean up.

Thanks,
Andrew


> +
>  # Return 1 if the current remote target is an instance of our GDBserver, 0
>  # otherwise.  Return -1 if there was an error and we can't tell.
>  
> @@ -5287,13 +5297,7 @@ proc gdb_continue_to_end {{mssg ""} {command continue} {allow_extra 0}} {
>    # loop, or a forced crash/reset.  For native targets, by default, we
>    # assume process exit is reported as such.  If a non-reliable target
>    # is used, we set a breakpoint at exit, and continue to that.
> -  if { [target_info exists exit_is_reliable] } {
> -      set exit_is_reliable [target_info exit_is_reliable]
> -  } else {
> -      set exit_is_reliable [expr ! $use_gdb_stub]
> -  }
> -
> -  if { ! $exit_is_reliable } {
> +  if ![exit_is_reliable] {
>      if {![gdb_breakpoint "exit"]} {
>        return 0
>      }
> -- 
> 2.25.0
> 

[PATCH 11/14] gdb/testsuite: Fix dbx.exp for remote targets

[Shahab Vahedi]

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

Testcase dbx.exp uses command "exec-file" but doesn't properly handle
the case of replacing one executable with another - it was handling the
case of local debugging, when inferior process is started by GDB, but
not the case of remote gdbserver, where message is different. Example
output, which is now handled is:

(gdb) file .../gdb.base/dbx/dbx
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Load new symbol table from .../gdb.base/dbx/dbx"? (y or n) y

gdb/testsuite/ChangeLog:
2016-08-19  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.base/dbx.exp (gdb_file_cmd): Add a case for
	changing the file.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/dbx.exp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gdb/testsuite/gdb.base/dbx.exp b/gdb/testsuite/gdb.base/dbx.exp
index d911fedf92cd..7993a658a314 100644
--- a/gdb/testsuite/gdb.base/dbx.exp
+++ b/gdb/testsuite/gdb.base/dbx.exp
@@ -183,6 +183,12 @@ proc gdb_file_cmd {arg} {
 	                verbose "\t\tKilling previous program being debugged"
 	            exp_continue
 	        }
+	        -re "A program is being debugged already.*change the file.*y or n. $" {
+		    # Handle the case of remote targets.
+	            send_gdb "y\n"
+	                verbose "\t\tChanging the file from previous program being debugged"
+	            exp_continue
+	        }
                 -re ".*$gdb_prompt $" {
                     verbose "\t\tLoaded $arg with new symbol table into $GDB"
                     return 0
-- 
2.25.0

Re: [PATCH 11/14] gdb/testsuite: Fix dbx.exp for remote targets

[Luis Machado]

On 2/7/20 12:00 PM, Shahab Vahedi wrote:
> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Testcase dbx.exp uses command "exec-file" but doesn't properly handle
> the case of replacing one executable with another - it was handling the
> case of local debugging, when inferior process is started by GDB, but
> not the case of remote gdbserver, where message is different. Example
> output, which is now handled is:

Is this again an artifact of starting a gdb+debugging stub setup with 
the program loaded as opposed to only starting gdb and then firing up 
the debugging stub?

> 
> (gdb) file .../gdb.base/dbx/dbx
> A program is being debugged already.
> Are you sure you want to change the file? (y or n) y
> Load new symbol table from .../gdb.base/dbx/dbx"? (y or n) y
> 

Is this still valid given the ChangeLog date? I don't see the file 
command being used, only exec-file and symbol-file.

> gdb/testsuite/ChangeLog:
> 2016-08-19  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/dbx.exp (gdb_file_cmd): Add a case for
> 	changing the file.
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>   gdb/testsuite/gdb.base/dbx.exp | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/dbx.exp b/gdb/testsuite/gdb.base/dbx.exp
> index d911fedf92cd..7993a658a314 100644
> --- a/gdb/testsuite/gdb.base/dbx.exp
> +++ b/gdb/testsuite/gdb.base/dbx.exp
> @@ -183,6 +183,12 @@ proc gdb_file_cmd {arg} {
>   	                verbose "\t\tKilling previous program being debugged"
>   	            exp_continue
>   	        }
> +	        -re "A program is being debugged already.*change the file.*y or n. $" {
> +		    # Handle the case of remote targets.
> +	            send_gdb "y\n"
> +	                verbose "\t\tChanging the file from previous program being debugged"
> +	            exp_continue
> +	        }
>                   -re ".*$gdb_prompt $" {
>                       verbose "\t\tLoaded $arg with new symbol table into $GDB"
>                       return 0
> 

[PATCH 02/14] gdb/testsuite: Skip fileio.exp for remote targets

[Shahab Vahedi]

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

fileio.exp naively assumes that it will be always running on a target
where application's output is printed into GDB's stdout. Wrong! If
application is run on a gdbserver, then its output is not printed into
GDB stdout.

gdb/testsuite/ChangeLog:
2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>

	* gdb.base/fileio.exp: Skip the test if remote.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.base/fileio.exp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
index 627a685e118d..241552691c38 100644
--- a/gdb/testsuite/gdb.base/fileio.exp
+++ b/gdb/testsuite/gdb.base/fileio.exp
@@ -25,6 +25,9 @@ standard_testfile
 
 if {[is_remote target]} {
     set outdir .
+    verbose "Skipping fileio.exp because it is truly broken for remote " \
+	"hosts with gdbservers."
+    continue
 } else {
     set outdir [standard_output_file {}]
 }
-- 
2.25.0

Re: [PATCH 02/14] gdb/testsuite: Skip fileio.exp for remote targets

[Luis Machado]

Hi,

On 2/7/20 11:59 AM, Shahab Vahedi wrote:
> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> fileio.exp naively assumes that it will be always running on a target
> where application's output is printed into GDB's stdout. Wrong! If
> application is run on a gdbserver, then its output is not printed into
> GDB stdout.

This relies on 01/14. The test does seem to be skipped when exercising 
the native-gdbserver/native-extended-gdbserver boards.

I think we should clarify 01/14 and merge this patch with that, since 
this is basically just printing some output when the test is skipped.

> 
> gdb/testsuite/ChangeLog:
> 2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/fileio.exp: Skip the test if remote.
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>   gdb/testsuite/gdb.base/fileio.exp | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
> index 627a685e118d..241552691c38 100644
> --- a/gdb/testsuite/gdb.base/fileio.exp
> +++ b/gdb/testsuite/gdb.base/fileio.exp
> @@ -25,6 +25,9 @@ standard_testfile
>   
>   if {[is_remote target]} {
>       set outdir .
> +    verbose "Skipping fileio.exp because it is truly broken for remote " \
> +	"hosts with gdbservers."
> +    continue
>   } else {
>       set outdir [standard_output_file {}]
>   }
> 

Re: [PATCH 02/14] gdb/testsuite: Skip fileio.exp for remote targets

[Andrew Burgess]

* Shahab Vahedi <shahab.vahedi@gmail.com> [2020-02-07 15:59:51 +0100]:

> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> fileio.exp naively assumes that it will be always running on a target
> where application's output is printed into GDB's stdout. Wrong! If
> application is run on a gdbserver, then its output is not printed into
> GDB stdout.
> 
> gdb/testsuite/ChangeLog:
> 2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/fileio.exp: Skip the test if remote.

See feedback for patch #1 in this series.  I think that explains why
you are running into this issue too.

Thanks,
Andrew


> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
> ---
>  gdb/testsuite/gdb.base/fileio.exp | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
> index 627a685e118d..241552691c38 100644
> --- a/gdb/testsuite/gdb.base/fileio.exp
> +++ b/gdb/testsuite/gdb.base/fileio.exp
> @@ -25,6 +25,9 @@ standard_testfile
>  
>  if {[is_remote target]} {
>      set outdir .
> +    verbose "Skipping fileio.exp because it is truly broken for remote " \
> +	"hosts with gdbservers."
> +    continue
>  } else {
>      set outdir [standard_output_file {}]
>  }
> -- 
> 2.25.0
> 

[PATCH 07/14] gdb/testsuite: Fix invalid watchpoint test in mi suite

[Shahab Vahedi]

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

GDB's watchpoints are triggered only if expression value has changed, so
memory at variable address already contained assigned value - watchpoint is
not triggered. Therefore it is not reliable to check watchpoints triggering
by checking first assignment - variable might already had that assigned
value, so GDB would ignore that new assignment. This can happen in real life
when same test case is run over an over again on baremetal - stack addresses
for local variables are constant and memory is persistent across runs. So
this code:

void callee4()
{
    int A = 1;
    int B = 2;
    int C;

    C = A + B;
}

might trigger watchpoint on C at the first execution, but not on subsequent
runs - memory address of C retained value 3 from first execution. Therefore
all watchpoint tests must have an initial assignment to some value, so that
variable contain a known value, and only then create a watchpoint, so that
this watchpoint would trigger reliably.

gdb/testsuite/ChangeLog:
2016-07-15  Anton Kolesov <Anton.Kolesov@synopsys.com>
	    Shahab Vahedi <shahab@synopsys.com>

	* gdb.mi/basics.c (callee4): Initialise "C" to 0.
	* gdb.mi/mi-cli.exp: Handle the introduced initialisation.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
---
 gdb/testsuite/gdb.mi/basics.c   |  2 +-
 gdb/testsuite/gdb.mi/mi-cli.exp | 15 +++++++++------
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/gdb/testsuite/gdb.mi/basics.c b/gdb/testsuite/gdb.mi/basics.c
index 7e7a74823afa..b3000a8020d3 100644
--- a/gdb/testsuite/gdb.mi/basics.c
+++ b/gdb/testsuite/gdb.mi/basics.c
@@ -26,7 +26,7 @@ int callee4 (void)
 {
   int A=1;
   int B=2;
-  int C;
+  int C=0;
 
   C = A + B;
   return 0;
diff --git a/gdb/testsuite/gdb.mi/mi-cli.exp b/gdb/testsuite/gdb.mi/mi-cli.exp
index 214cc8a479e6..82f050a83c32 100644
--- a/gdb/testsuite/gdb.mi/mi-cli.exp
+++ b/gdb/testsuite/gdb.mi/mi-cli.exp
@@ -68,8 +68,9 @@ set line_main_return  [expr $line_main_hello + 2]
 set line_main_callme_2 [expr $line_main_return + 1]
 set line_callee4_head [gdb_get_line_number "callee4 ("]
 set line_callee4_body [expr $line_callee4_head + 2]
-set line_callee4_next [expr $line_callee4_body + 1]
-set line_callee4_next_step [expr $line_callee4_next + 3]
+set line_callee4_first_next [expr $line_callee4_body + 1]
+set line_callee4_second_next [expr $line_callee4_first_next + 1]
+set line_callee4_third_next [expr $line_callee4_second_next + 2]
 
 mi_gdb_test "-interpreter-exec console \"set args foobar\"" \
   ".*=cmd-param-changed,param=\"args\",value=\"foobar\".*\\^done" \
@@ -136,10 +137,12 @@ mi_gdb_test "500-stack-select-frame 0" \
   {500\^done} \
   "-stack-select-frame 0"
 
-mi_execute_to "interpreter-exec console step" "end-stepping-range" "callee4" "" ".*basics.c" $line_callee4_next \
+mi_execute_to "interpreter-exec console step" "end-stepping-range" "callee4" "" ".*basics.c" $line_callee4_first_next \
     "" "check *stopped from CLI command"
 
-mi_send_resuming_command "exec-step" "-exec-step to line \$line_callee4_next_step"
+mi_step_to "callee4" "" ".*basics.c" $line_callee4_second_next "step over B's initialization"
+
+mi_send_resuming_command "exec-step" "-exec-step to line $line_callee4_third_next"
 
 # Test that the new current source line is _not_ output, given we
 # executed MI's -exec-next, not CLI's 'next' command.
@@ -153,8 +156,8 @@ if {[regexp "A + B" "$output"]} {
     pass $test
 }
 
-mi_expect_stop "end-stepping-range" "callee4" "" ".*basics.c" $line_callee4_next_step \
-    "" "check *stopped from CLI command 2"
+mi_expect_stop "end-stepping-range" "callee4" "" ".*basics.c" $line_callee4_third_next \
+    "" "check *stopped from CLI command 3"
 
 # Test that CLI's "finish" command prints the function's return value
 # to both the CLI and MI streams, and that the same result variable is
-- 
2.25.0

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

[Shahab Vahedi]

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

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

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

[Luis Machado]

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

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

[Shahab Vahedi]

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

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

[Anton Kolesov]

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

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

[Andrew Burgess]

* 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