2012-11-02 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/ChangeLog

@@ -1,3 +1,10 @@
+2012-11-02  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.
+
 2012-11-02  Pedro Alves  <palves@redhat.com>
 
 	Don't hard code line numbers.

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
+   if { [istarget "hppa*-*-hpux*"] && ![istarget "hppa*-*-hpux11.*"] } {
-# debugging of a vforking program basically doesn't allow the child to do
+      # This test cannot be performed prior to HP-UX 10.30, because
-# things like hit a breakpoint between a vfork and exec.  This means that
+      # ptrace-based debugging of a vforking program basically doesn't
-# saying "set follow-fork child; next" at a vfork() call won't work, because
+      # allow the child to do things like hit a breakpoint between a
-# the implementation of "next" sets a "step resume" breakpoint at the
+      # vfork and exec.  This means that saying "set follow-fork
-# return from the vfork(), which the child will hit on its way to exec'ing.
+      # child; next" at a vfork() call won't work, because the
-#
+      # implementation of "next" sets a "step resume" breakpoint at
-   if { ![istarget "hppa*-*-hpux11.*"] } {
+      # the return from the vfork(), which the child will hit on its
-      verbose "vfork child-following next test ignored for non-hppa or pre-HP/UX-10.30 targets."
+      # 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}]
+   if { [istarget "hppa*-*-hpux*"]} {
-   gdb_test_multiple "next" $test {
+       # Since the child cannot be debugged until after it has exec'd,
-      -re "Attaching after fork to.*Executing new program.*Breakpoint.*vforked-prog.c:${linenum}.*$gdb_prompt " {
+       # and since there's a bp on "main" in the parent, and since the
-	  pass "$test"
+       # 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