[PATCH 0/2] Make catch-syscall.exp work with "target remote".

[PATCH 0/2] Make catch-syscall.exp work with "target remote".

[Pedro Alves]

Running the pending GDBserver "catch syscall" patch against the
native-gdbserver.exp board ("target remote", instead of the
native-extended-gdbserver.exp board ("target extended-remote") fails
the existing catch-syscall.exp test.  These look like problems with
the testsuite, actually independent of the catch syscall support, so I
took a stab at fixing them.

Unfortunately, the first patch regresses testing against the stdio
board.  The second patch fixes that.  If people are OK with these
patches, I'll swap their order before check in.

Pedro Alves (2):
  Make catch-syscall.exp work with "target remote".  A.k.a., teach the
    testsuite that GDBserver reliably reports program exits.
  [GDBserver]: Silence exits if GDB is connected through stdio.

 gdb/gdbserver/server.c                          |  5 ++++-
 gdb/gdbserver/target.c                          | 23 ++++++++++++++++-------
 gdb/testsuite/README                            |  8 ++++++++
 gdb/testsuite/boards/native-gdbserver.exp       |  1 +
 gdb/testsuite/boards/native-stdio-gdbserver.exp |  1 +
 gdb/testsuite/lib/gdb.exp                       | 21 +++++++++++++++------
 6 files changed, 45 insertions(+), 14 deletions(-)

-- 
1.7.11.7

[PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.

[Pedro Alves]

After the previous patch, catch-syscall.exp still doesn't pass with
the native-stdio-gdbserver.exp board.  We get:

 (gdb) continue
 Continuing.

 Child exited with status 0
 GDBserver exiting
 [Inferior 1 (process 22721) exited normally]
 (gdb) FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)

The problem is the whole "Child exited ... GDBserver exiting" output,
that comes out of GDBserver, and that the testsuite is not expecting.

In fact, the previous patch adds a bunch of regressions with this
board due to this, not just to catch-syscall.exp:

-PASS: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step
+FAIL: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step (the program exited)
-PASS: gdb.base/break.exp: continue until exit at recursive next test
+FAIL: gdb.base/break.exp: continue until exit at recursive next test (the program exited)
-PASS: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through
+FAIL: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through (the program exited)
... etc. ...

(I plan to swap the order of the patches before check in, to prevent
breaking bisects.)

I pondered somehow making the testsuite adjust to this.  But,
testsuite aside, I think GDBserver should not be outputting this at
all when GDB is connected through stdio.  GDBserver will be printing
this in GDB's console, but the user can already tell from the regular
output that the inferior is gone.

Again, manually:

 (gdb) tar remote | ./gdbserver/gdbserver - program
 Remote debugging using | ./gdbserver/gdbserver - program
 Process program created; pid = 22486
 stdin/stdout redirected
 Remote debugging using stdio
 done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 0x000000323d001530 in _start () from /lib64/ld-linux-x86-64.so.2
 (gdb) c
 Continuing.
 Child exited with status 1
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 GDBserver exiting
 ^^^^^^^^^^^^^^^^^
 [Inferior 1 (process 22486) exited with code 01]
 (gdb)

Suppressing those two lines makes the output be exactly like when
debugging against a remote tcp gdbserver:

 (gdb) c
 Continuing.
 [Inferior 1 (process 22914) exited with code 01]
 (gdb)

Comments?

2013-09-27  Pedro Alves  <palves@redhat.com>

	* server.c (process_serial_event): Don't output "GDBserver
	exiting" if GDB is connected through stdio.
	* target.c (mywait): Likewise, be silent if GDB is connected
	through stdio.
---
 gdb/gdbserver/server.c |  5 ++++-
 gdb/gdbserver/target.c | 23 ++++++++++++++++-------
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index 4de20d5..e0af785 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -3550,7 +3550,10 @@ process_serial_event (void)
 	 the whole vStopped list (until it gets an OK).  */
       if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
 	{
-	  fprintf (stderr, "GDBserver exiting\n");
+	  /* Be transparent when GDB is connected through stdio -- no
+	     need to spam GDB's console.  */
+	  if (!remote_connection_is_stdio ())
+	    fprintf (stderr, "GDBserver exiting\n");
 	  remote_close ();
 	  exit (0);
 	}
diff --git a/gdb/gdbserver/target.c b/gdb/gdbserver/target.c
index 1a0dee2..64940e2 100644
--- a/gdb/gdbserver/target.c
+++ b/gdb/gdbserver/target.c
@@ -82,13 +82,22 @@ mywait (ptid_t ptid, struct target_waitstatus *ourstatus, int options,
 
   ret = (*the_target->wait) (ptid, ourstatus, options);
 
-  if (ourstatus->kind == TARGET_WAITKIND_EXITED)
-    fprintf (stderr,
-	     "\nChild exited with status %d\n", ourstatus->value.integer);
-  else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
-    fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
-	     gdb_signal_to_host (ourstatus->value.sig),
-	     gdb_signal_to_name (ourstatus->value.sig));
+  /* If GDB is connected through TCP/serial, then GDBserver will most
+     probably be running on its own terminal/console, so it's nice to
+     print there why is GDBserver existing.  If however, GDB is
+     connected through stdio, then there's no need to spam the GDB
+     console with this -- the user will already see the exit through
+     regular GDB output, in that same terminal.  */
+  if (!remote_connection_is_stdio ())
+    {
+      if (ourstatus->kind == TARGET_WAITKIND_EXITED)
+	fprintf (stderr,
+		 "\nChild exited with status %d\n", ourstatus->value.integer);
+      else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
+	fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
+		 gdb_signal_to_host (ourstatus->value.sig),
+		 gdb_signal_to_name (ourstatus->value.sig));
+    }
 
   if (connected_wait)
     server_waiting = 0;
-- 
1.7.11.7

Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.

[Sergio Durigan Junior]

On Friday, September 27 2013, Pedro Alves wrote:

> After the previous patch, catch-syscall.exp still doesn't pass with
> the native-stdio-gdbserver.exp board.  We get:
>
>  (gdb) continue
>  Continuing.
>
>  Child exited with status 0
>  GDBserver exiting
>  [Inferior 1 (process 22721) exited normally]
>  (gdb) FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
>
> The problem is the whole "Child exited ... GDBserver exiting" output,
> that comes out of GDBserver, and that the testsuite is not expecting.

FWIW, I agree with this patch.  I hadn't tested catch syscall using
neither native{,-stdio}-gdbserver, so I didn't catch those errors.
Sorry about that.

> In fact, the previous patch adds a bunch of regressions with this
> board due to this, not just to catch-syscall.exp:
>
> -PASS: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step
> +FAIL: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step (the program exited)
> -PASS: gdb.base/break.exp: continue until exit at recursive next test
> +FAIL: gdb.base/break.exp: continue until exit at recursive next test (the program exited)
> -PASS: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through
> +FAIL: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through (the program exited)
> ... etc. ...
>
> (I plan to swap the order of the patches before check in, to prevent
> breaking bisects.)
>
> I pondered somehow making the testsuite adjust to this.  But,
> testsuite aside, I think GDBserver should not be outputting this at
> all when GDB is connected through stdio.  GDBserver will be printing
> this in GDB's console, but the user can already tell from the regular
> output that the inferior is gone.
>
> Again, manually:
>
>  (gdb) tar remote | ./gdbserver/gdbserver - program
>  Remote debugging using | ./gdbserver/gdbserver - program
>  Process program created; pid = 22486
>  stdin/stdout redirected
>  Remote debugging using stdio
>  done.
>  Loaded symbols for /lib64/ld-linux-x86-64.so.2
>  0x000000323d001530 in _start () from /lib64/ld-linux-x86-64.so.2
>  (gdb) c
>  Continuing.
>  Child exited with status 1
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^
>  GDBserver exiting
>  ^^^^^^^^^^^^^^^^^
>  [Inferior 1 (process 22486) exited with code 01]
>  (gdb)
>
> Suppressing those two lines makes the output be exactly like when
> debugging against a remote tcp gdbserver:
>
>  (gdb) c
>  Continuing.
>  [Inferior 1 (process 22914) exited with code 01]
>  (gdb)
>
> Comments?

Patch is fine by me, thanks!

> 2013-09-27  Pedro Alves  <palves@redhat.com>
>
> 	* server.c (process_serial_event): Don't output "GDBserver
> 	exiting" if GDB is connected through stdio.
> 	* target.c (mywait): Likewise, be silent if GDB is connected
> 	through stdio.
> ---
>  gdb/gdbserver/server.c |  5 ++++-
>  gdb/gdbserver/target.c | 23 ++++++++++++++++-------
>  2 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
> index 4de20d5..e0af785 100644
> --- a/gdb/gdbserver/server.c
> +++ b/gdb/gdbserver/server.c
> @@ -3550,7 +3550,10 @@ process_serial_event (void)
>  	 the whole vStopped list (until it gets an OK).  */
>        if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
>  	{
> -	  fprintf (stderr, "GDBserver exiting\n");
> +	  /* Be transparent when GDB is connected through stdio -- no
> +	     need to spam GDB's console.  */
> +	  if (!remote_connection_is_stdio ())
> +	    fprintf (stderr, "GDBserver exiting\n");
>  	  remote_close ();
>  	  exit (0);
>  	}
> diff --git a/gdb/gdbserver/target.c b/gdb/gdbserver/target.c
> index 1a0dee2..64940e2 100644
> --- a/gdb/gdbserver/target.c
> +++ b/gdb/gdbserver/target.c
> @@ -82,13 +82,22 @@ mywait (ptid_t ptid, struct target_waitstatus *ourstatus, int options,
>  
>    ret = (*the_target->wait) (ptid, ourstatus, options);
>  
> -  if (ourstatus->kind == TARGET_WAITKIND_EXITED)
> -    fprintf (stderr,
> -	     "\nChild exited with status %d\n", ourstatus->value.integer);
> -  else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
> -    fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
> -	     gdb_signal_to_host (ourstatus->value.sig),
> -	     gdb_signal_to_name (ourstatus->value.sig));
> +  /* If GDB is connected through TCP/serial, then GDBserver will most
> +     probably be running on its own terminal/console, so it's nice to
> +     print there why is GDBserver existing.  If however, GDB is
> +     connected through stdio, then there's no need to spam the GDB
> +     console with this -- the user will already see the exit through
> +     regular GDB output, in that same terminal.  */
> +  if (!remote_connection_is_stdio ())
> +    {
> +      if (ourstatus->kind == TARGET_WAITKIND_EXITED)
> +	fprintf (stderr,
> +		 "\nChild exited with status %d\n", ourstatus->value.integer);
> +      else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
> +	fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
> +		 gdb_signal_to_host (ourstatus->value.sig),
> +		 gdb_signal_to_name (ourstatus->value.sig));
> +    }
>  
>    if (connected_wait)
>      server_waiting = 0;
> -- 
> 1.7.11.7

-- 
Sergio

Re: [PATCH 2/2] [GDBserver]: Silence exits if GDB is connected through stdio.

[Pedro Alves]

On 09/27/2013 09:41 PM, Sergio Durigan Junior wrote:
> FWIW, I agree with this patch.  I hadn't tested catch syscall using
> neither native{,-stdio}-gdbserver, so I didn't catch those errors.
> Sorry about that.

No worries.

>> >
>> > Comments?
> Patch is fine by me, thanks!

Great, I've applied this now, as below.

-------
[GDBserver]: Silence exits if GDB is connected through stdio.

If we make gdbserver gdb_continue_to_end actually expect a process
exit with GDBserver, we get many testsuite failures with the remote
stdio board:

-PASS: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step
+FAIL: gdb.arch/amd64-disp-step.exp: continue until exit at amd64-disp-step (the program exited)
-PASS: gdb.base/break.exp: continue until exit at recursive next test
+FAIL: gdb.base/break.exp: continue until exit at recursive next test (the program exited)
-PASS: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through
+FAIL: gdb.base/chng-syms.exp: continue until exit at breakpoint first time through (the program exited)
... etc. ...

This is what the log shows for all of them:

 (gdb) continue
 Continuing.

 Child exited with status 0
 GDBserver exiting
 [Inferior 1 (process 22721) exited normally]
 (gdb) FAIL: gdb.arch/amd64-disp-step.exp: continue until exit (the program exited)

The problem is the whole "Child exited ... GDBserver exiting" output,
that comes out of GDBserver, and that the testsuite is not expecting.

I pondered somehow making the testsuite adjust to this.  But,
testsuite aside, I think GDBserver should not be outputting this at
all when GDB is connected through stdio.  GDBserver will be printing
this in GDB's console, but the user can already tell from the regular
output that the inferior is gone.

Again, manually:

 (gdb) tar remote | ./gdbserver/gdbserver - program
 Remote debugging using | ./gdbserver/gdbserver - program
 Process program created; pid = 22486
 stdin/stdout redirected
 Remote debugging using stdio
 done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 0x000000323d001530 in _start () from /lib64/ld-linux-x86-64.so.2
 (gdb) c
 Continuing.
 Child exited with status 1
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 GDBserver exiting
 ^^^^^^^^^^^^^^^^^
 [Inferior 1 (process 22486) exited with code 01]
 (gdb)

Suppressing those two lines makes the output be exactly like when
debugging against a remote tcp gdbserver:

 (gdb) c
 Continuing.
 [Inferior 1 (process 22914) exited with code 01]
 (gdb)

2013-10-02  Pedro Alves  <palves@redhat.com>

	* server.c (process_serial_event): Don't output "GDBserver
	exiting" if GDB is connected through stdio.
	* target.c (mywait): Likewise, be silent if GDB is connected
	through stdio.

---

 gdb/gdbserver/server.c |    5 ++++-
 gdb/gdbserver/target.c |   23 ++++++++++++++++-------
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index 4de20d5..e0af785 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -3550,7 +3550,10 @@ process_serial_event (void)
 	 the whole vStopped list (until it gets an OK).  */
       if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
 	{
-	  fprintf (stderr, "GDBserver exiting\n");
+	  /* Be transparent when GDB is connected through stdio -- no
+	     need to spam GDB's console.  */
+	  if (!remote_connection_is_stdio ())
+	    fprintf (stderr, "GDBserver exiting\n");
 	  remote_close ();
 	  exit (0);
 	}
diff --git a/gdb/gdbserver/target.c b/gdb/gdbserver/target.c
index 1a0dee2..d4a2a98 100644
--- a/gdb/gdbserver/target.c
+++ b/gdb/gdbserver/target.c
@@ -82,13 +82,22 @@ mywait (ptid_t ptid, struct target_waitstatus *ourstatus, int options,
 
   ret = (*the_target->wait) (ptid, ourstatus, options);
 
-  if (ourstatus->kind == TARGET_WAITKIND_EXITED)
-    fprintf (stderr,
-	     "\nChild exited with status %d\n", ourstatus->value.integer);
-  else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
-    fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
-	     gdb_signal_to_host (ourstatus->value.sig),
-	     gdb_signal_to_name (ourstatus->value.sig));
+  /* If GDB is connected through TCP/serial, then GDBserver will most
+     probably be running on its own terminal/console, so it's nice to
+     print there why is GDBserver exiting.  If however, GDB is
+     connected through stdio, then there's no need to spam the GDB
+     console with this -- the user will already see the exit through
+     regular GDB output, in that same terminal.  */
+  if (!remote_connection_is_stdio ())
+    {
+      if (ourstatus->kind == TARGET_WAITKIND_EXITED)
+	fprintf (stderr,
+		 "\nChild exited with status %d\n", ourstatus->value.integer);
+      else if (ourstatus->kind == TARGET_WAITKIND_SIGNALLED)
+	fprintf (stderr, "\nChild terminated with signal = 0x%x (%s)\n",
+		 gdb_signal_to_host (ourstatus->value.sig),
+		 gdb_signal_to_name (ourstatus->value.sig));
+    }
 
   if (connected_wait)
     server_waiting = 0;

[PATCH 1/2] Make catch-syscall.exp work with "target remote". A.k.a., teach the testsuite that GDBserver reliably reports program exits.

[Pedro Alves]

Running catch-syscall.exp against a gdbserver that actually supports
it, we get:

 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit at catch syscall with unused syscall (mlock) (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)

The fail pattern is:

 Catchpoint 2 (call to syscall exit_group), 0x000000323d4baa29 in _exit () from /lib64/libc.so.6
 (gdb) PASS: gdb.base/catch-syscall.exp: program has called exit_group
 delete breakpoints
 Delete all breakpoints? (y or n) y
 (gdb) info breakpoints
 No breakpoints or watchpoints.
 (gdb) break exit
 Breakpoint 3 at 0x323d438bf0
 (gdb) continue
 Continuing.
 [Inferior 1 (process 21081) exited normally]

That "break exit" + "continue" comes from:

> # gdb_continue_to_end:
> #	The case where the target uses stubs has to be handled specially. If a
> #       stub is used, we set a breakpoint at exit because we cannot rely on
> #       exit() behavior of a remote target.
> #

The native-gdbserver.exp board, used to test against gdbserver in
"target remote" mode, triggers that case ($use_gdb_stub is true).  So
gdb_continue_to_end doesn't work for catch-syscall.exp as here we
catch the exit_group and continue from that, expecting to see a real
program exit.  I was about to post a patch that changes
catch-syscall.exp to call a new function that just always does what
gdb_continue_to_end does in the !$use_gdb_stub case.  But, since
GDBserver doesn't really need this, in the end I thought it better to
teach the testsuite that there are stubs that know how to report
program exits, by adding a new "exit_is_reliable" board variable that
then gdb_continue_to_end checks.

Tested on x86_64 Fedora 17, native and gdbserver.

Comments?

gdb/testsuite/
2013-09-27  Pedro Alves  <palves@redhat.com>

	* README (Board Settings): Document "exit_is_reliable".
	* lib/gdb.exp (gdb_continue_to_end): Check whether the board says
	running to exit reliably reports program exits.
	* boards/native-gdbserver.exp: Set exit_is_reliable in the board
	info.
	* boards/native-stdio-gdbserver.exp: Likewise.
---
 gdb/testsuite/README                            |  8 ++++++++
 gdb/testsuite/boards/native-gdbserver.exp       |  1 +
 gdb/testsuite/boards/native-stdio-gdbserver.exp |  1 +
 gdb/testsuite/lib/gdb.exp                       | 21 +++++++++++++++------
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/README b/gdb/testsuite/README
index 4d369c5..ba18c29 100644
--- a/gdb/testsuite/README
+++ b/gdb/testsuite/README
@@ -247,6 +247,14 @@ use_gdb_stub
 
   The tests are running with a GDB stub.
 
+exit_is_reliable
+
+  Set to true if although running with a GDB stub, GDB can assume that
+  letting the program run to end reliably results in program exit
+  being reported (as opposed, e.g., the program ending in an infinite
+  loop or the board crashing/resetting).  If not set, this defaults to
+  $use_gdb_stub.
+
 gdb,predefined_tsv
 
   The predefined trace state variables the board has.
diff --git a/gdb/testsuite/boards/native-gdbserver.exp b/gdb/testsuite/boards/native-gdbserver.exp
index 6c1430f..ab239ec 100644
--- a/gdb/testsuite/boards/native-gdbserver.exp
+++ b/gdb/testsuite/boards/native-gdbserver.exp
@@ -31,6 +31,7 @@ set_board_info noargs 1
 
 set_board_info sockethost "localhost:"
 set_board_info use_gdb_stub 1
+set_board_info exit_is_reliable 1
 
 # We will be using the standard GDB remote protocol.
 set_board_info gdb_protocol "remote"
diff --git a/gdb/testsuite/boards/native-stdio-gdbserver.exp b/gdb/testsuite/boards/native-stdio-gdbserver.exp
index 3b99909..a093904 100644
--- a/gdb/testsuite/boards/native-stdio-gdbserver.exp
+++ b/gdb/testsuite/boards/native-stdio-gdbserver.exp
@@ -34,6 +34,7 @@ set_board_info sockethost "stdio"
 set_board_info gdb,socketport ""
 set_board_info gdb,get_remote_address ${board}_get_remote_address
 set_board_info use_gdb_stub 1
+set_board_info exit_is_reliable 1
 
 # We will be using the standard GDB remote protocol.
 set_board_info gdb_protocol "remote"
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 5e3331a..620dbc3 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3806,11 +3806,8 @@ proc gdb_get_line_number { text { file "" } } {
     return $found
 }
 
-# gdb_continue_to_end:
-#	The case where the target uses stubs has to be handled specially. If a
-#       stub is used, we set a breakpoint at exit because we cannot rely on
-#       exit() behavior of a remote target.
-# 
+# Continue the program until it ends.
+#
 # MSSG is the error message that gets printed.  If not given, a
 #	default is used.
 # COMMAND is the command to invoke.  If not given, "continue" is
@@ -3833,7 +3830,19 @@ proc gdb_continue_to_end {{mssg ""} {command continue} {allow_extra 0}} {
   } else {
       set extra ""
   }
-  if $use_gdb_stub {
+
+  # By default, we don't rely on exit() behavior of remote stubs.
+  # When the program exits, the target may end up in an infinite loop,
+  # or even crash/reset.  For native targets, by default, we assume
+  # exit is reliable.  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 {![gdb_breakpoint "exit"]} {
       return 0
     }
-- 
1.7.11.7

Re: [PATCH 1/2] Make catch-syscall.exp work with "target remote". A.k.a., teach the testsuite that GDBserver reliably reports program exits.

[Pedro Alves]

Now applied as well (after patch 2/2), as below.

-----
Subject: Teach the testsuite that GDBserver reliably reports program exits.

Running catch-syscall.exp against a gdbserver that actually supports
it, we get:

 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit at catch syscall with unused syscall (mlock) (the program exited)
 FAIL: gdb.base/catch-syscall.exp: continue until exit (the program exited)

The fail pattern is:

 Catchpoint 2 (call to syscall exit_group), 0x000000323d4baa29 in _exit () from /lib64/libc.so.6
 (gdb) PASS: gdb.base/catch-syscall.exp: program has called exit_group
 delete breakpoints
 Delete all breakpoints? (y or n) y
 (gdb) info breakpoints
 No breakpoints or watchpoints.
 (gdb) break exit
 Breakpoint 3 at 0x323d438bf0
 (gdb) continue
 Continuing.
 [Inferior 1 (process 21081) exited normally]

That "break exit" + "continue" comes from:

> # gdb_continue_to_end:
> #	The case where the target uses stubs has to be handled specially. If a
> #       stub is used, we set a breakpoint at exit because we cannot rely on
> #       exit() behavior of a remote target.
> #

The native-gdbserver.exp board, used to test against gdbserver in
"target remote" mode, triggers that case ($use_gdb_stub is true).  So
gdb_continue_to_end doesn't work for catch-syscall.exp as here we
catch the exit_group and continue from that, expecting to see a real
program exit.  I was about to post a patch that changes
catch-syscall.exp to call a new function that just always does what
gdb_continue_to_end does in the !$use_gdb_stub case.  But, since
GDBserver doesn't really need this, in the end I thought it better to
teach the testsuite that there are stubs that know how to report
program exits, by adding a new "exit_is_reliable" board variable that
then gdb_continue_to_end checks.

Tested on x86_64 Fedora 17, native and gdbserver.

gdb/testsuite/
2013-10-02  Pedro Alves  <palves@redhat.com>

	* README (Board Settings): Document "exit_is_reliable".
	* lib/gdb.exp (gdb_continue_to_end): Check whether the board says
	running to exit reliably reports program exits.
	* boards/native-gdbserver.exp: Set exit_is_reliable in the board
	info.
	* boards/native-stdio-gdbserver.exp: Likewise.

---

 gdb/testsuite/README                            |    9 +++++++++
 gdb/testsuite/boards/native-gdbserver.exp       |    1 +
 gdb/testsuite/boards/native-stdio-gdbserver.exp |    1 +
 gdb/testsuite/lib/gdb.exp                       |   21 +++++++++++++++------
 4 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/README b/gdb/testsuite/README
index 4d369c5..ec91b14 100644
--- a/gdb/testsuite/README
+++ b/gdb/testsuite/README
@@ -247,6 +247,15 @@ use_gdb_stub
 
   The tests are running with a GDB stub.
 
+exit_is_reliable
+
+  Set to true if GDB can assume that letting the program run to end
+  reliably results in program exits being reported as such, as opposed
+  to, e.g., the program ending in an infinite loop or the board
+  crashing/resetting.  If not set, this defaults to $use_gdb_stub.  In
+  other words, native targets are assumed reliable by default, and
+  remote stubs assumed unreliable.
+
 gdb,predefined_tsv
 
   The predefined trace state variables the board has.
diff --git a/gdb/testsuite/boards/native-gdbserver.exp b/gdb/testsuite/boards/native-gdbserver.exp
index 6c1430f..ab239ec 100644
--- a/gdb/testsuite/boards/native-gdbserver.exp
+++ b/gdb/testsuite/boards/native-gdbserver.exp
@@ -31,6 +31,7 @@ set_board_info noargs 1
 
 set_board_info sockethost "localhost:"
 set_board_info use_gdb_stub 1
+set_board_info exit_is_reliable 1
 
 # We will be using the standard GDB remote protocol.
 set_board_info gdb_protocol "remote"
diff --git a/gdb/testsuite/boards/native-stdio-gdbserver.exp b/gdb/testsuite/boards/native-stdio-gdbserver.exp
index 3b99909..a093904 100644
--- a/gdb/testsuite/boards/native-stdio-gdbserver.exp
+++ b/gdb/testsuite/boards/native-stdio-gdbserver.exp
@@ -34,6 +34,7 @@ set_board_info sockethost "stdio"
 set_board_info gdb,socketport ""
 set_board_info gdb,get_remote_address ${board}_get_remote_address
 set_board_info use_gdb_stub 1
+set_board_info exit_is_reliable 1
 
 # We will be using the standard GDB remote protocol.
 set_board_info gdb_protocol "remote"
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 5e3331a..6c9948f 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3806,11 +3806,8 @@ proc gdb_get_line_number { text { file "" } } {
     return $found
 }
 
-# gdb_continue_to_end:
-#	The case where the target uses stubs has to be handled specially. If a
-#       stub is used, we set a breakpoint at exit because we cannot rely on
-#       exit() behavior of a remote target.
-# 
+# Continue the program until it ends.
+#
 # MSSG is the error message that gets printed.  If not given, a
 #	default is used.
 # COMMAND is the command to invoke.  If not given, "continue" is
@@ -3833,7 +3830,19 @@ proc gdb_continue_to_end {{mssg ""} {command continue} {allow_extra 0}} {
   } else {
       set extra ""
   }
-  if $use_gdb_stub {
+
+  # By default, we don't rely on exit() behavior of remote stubs --
+  # it's common for exit() to be implemented as a simple infinite
+  # 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 {![gdb_breakpoint "exit"]} {
       return 0
     }