[PATCH 3/8] foll-vfork.exp: Expose more testing on non-HP/UX targets

[Pedro Alves <palves@redhat.com>]

Well, exposes more to Linux, since we have at the top:

if {![istarget "hppa*-hp-hpux*"] && ![istarget "*-linux*"]} then {
    continue
}

The vfork_and_exec_child_follow_through_step procedure is about
following the child over a "next".  This is currently disabled on non
HP/UX targets, but it's a useful test to run.  AFAICS from the test,
HP/UX can't debug the vfork child until it execs or exits.  The Linux
kernel can, so the test is adjusted to expect the ideal behavior out
of non HP/UX targets (and we get that right on Linux).

gdb/testsuite/
2012-10-25  Pedro Alves  <palves@redhat.com>

	* gdb.base/foll-vfork.exp
	(vfork_and_exec_child_follow_through_step): Don't skip on
	non-HP/UX targets.  Expect the next to only step one line on
	non-HP/UX targets, rather than stopping only after the exec.
---
 gdb/testsuite/gdb.base/foll-vfork.exp |   47 +++++++++++++++++++++++----------
 1 file changed, 33 insertions(+), 14 deletions(-)

diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp
index 67d077d..54f5971 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -183,15 +183,17 @@ proc vfork_and_exec_child_follow_through_step {} {
    global gdb_prompt
    global srcfile2
 
-# This test cannot be performed prior to HP-UX 10.30, because ptrace-based
-# debugging of a vforking program basically doesn't allow the child to do
-# things like hit a breakpoint between a vfork and exec.  This means that
-# saying "set follow-fork child; next" at a vfork() call won't work, because
-# the implementation of "next" sets a "step resume" breakpoint at the
-# return from the vfork(), which the child will hit on its way to exec'ing.
-#
-   if { ![istarget "hppa*-*-hpux11.*"] } {
-      verbose "vfork child-following next test ignored for non-hppa or pre-HP/UX-10.30 targets."
+   if { [istarget "hppa*-*-hpux*"] && ![istarget "hppa*-*-hpux11.*"] } {
+      # This test cannot be performed prior to HP-UX 10.30, because
+      # ptrace-based debugging of a vforking program basically doesn't
+      # allow the child to do things like hit a breakpoint between a
+      # vfork and exec.  This means that saying "set follow-fork
+      # child; next" at a vfork() call won't work, because the
+      # implementation of "next" sets a "step resume" breakpoint at
+      # the return from the vfork(), which the child will hit on its
+      # way to exec'ing.
+      #
+      verbose "vfork child-following next test ignored for pre-HP/UX-10.30 targets."
       return 0
    }
 
@@ -200,11 +202,28 @@ proc vfork_and_exec_child_follow_through_step {} {
        "set follow-fork child, vfork and exec through step"
 
    set test "vfork and exec child follow, through step"
-   set linenum [gdb_get_line_number "printf(\"Hello from vforked-prog" ${srcfile2}]
-   gdb_test_multiple "next" $test {
-      -re "Attaching after fork to.*Executing new program.*Breakpoint.*vforked-prog.c:${linenum}.*$gdb_prompt " {
-	  pass "$test"
-      }
+   if { [istarget "hppa*-*-hpux*"]} {
+       # Since the child cannot be debugged until after it has exec'd,
+       # and since there's a bp on "main" in the parent, and since the
+       # bp's for the parent are recomputed in the exec'd child, the
+       # step through a vfork should land us in the "main" for the
+       # exec'd child, too.
+       #
+       set linenum [gdb_get_line_number "printf(\"Hello from vforked-prog" ${srcfile2}]
+       gdb_test_multiple "next" $test {
+	   -re "Attaching after fork to.*Executing new program.*Breakpoint.*vforked-prog.c:${linenum}.*$gdb_prompt " {
+	       pass "$test"
+	   }
+       }
+   } else {
+       # The ideal support is to be able to debug the child even
+       # before it execs.  Thus, "next" lands on the next line after
+       # the vfork.
+       gdb_test_multiple "next" $test {
+	   -re "Attaching after .* vfork to child.*if \\(pid == 0\\).*$gdb_prompt " {
+	       pass "$test"
+	   }
+       }
    }
    # The parent has been detached; allow time for any output it might
    # generate to arrive, so that output doesn't get confused with