2012-11-02 Pedro Alves <palves@redhat.com>
authorPedro Alves <palves@redhat.com>
Fri, 2 Nov 2012 17:58:39 +0000 (17:58 +0000)
committerPedro Alves <palves@redhat.com>
Fri, 2 Nov 2012 17:58:39 +0000 (17:58 +0000)
* 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
gdb/testsuite/gdb.base/foll-vfork.exp

index 426b07bbe8df46ac33d5d8f4cafaedeebf40a7b5..aa8388af0dc5b5eab7f63f41581cecee4195e760 100644 (file)
@@ -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.
index 67d077dd2c7281bdcd9f991c9164ed2aabc5d134..54f5971ca3719447bcc20529d5856bda89828c18 100644 (file)
@@ -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