From: Pedro Alves Date: Fri, 2 Nov 2012 17:58:39 +0000 (+0000) Subject: 2012-11-02 Pedro Alves X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=6dbc89975ec5436e2132a79412651ade6e465bdb;p=binutils-gdb.git 2012-11-02 Pedro Alves * 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. --- diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 426b07bbe8d..aa8388af0dc 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,10 @@ +2012-11-02 Pedro Alves + + * 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 Don't hard code line numbers. diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp index 67d077dd2c7..54f5971ca37 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