This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA] break.exp: bt & finish from dummy call


Yes, I think it is a good test improvement, although I the
backtrace and finish with dummy frames are already tested elsewhere.
I can't see no reason myself to leave it restricted to HP though.

We recently added tests that depend on this to be working so you will
only be hit by targets that hit those as well.  We decided that we were 
going to fix it when we notice that they were failing.

Go ahead and thanks for the improvement (and fix for remote targets).

Fernando


Nick Duffek wrote:
> 
> This patch fixes a break.exp failure when testing remote targets.  Without
> the patch, break.exp does the following on non-HP-UX systems:
> 
>   break marker2
>   print marker2 (99)          # GDB stops in the dummy call to marker2
>   runto_main
> 
> On remote targets, runto_main jumps to the program's entry point, which
> contains the dummy breakpoint if CALL_DUMMY_LOCATION == AT_ENTRY_POINT.
> GDB therefore stops at that breakpoint instead of in main as expected by
> runto_main, with test failures as a result.
> 
> On HP-UX systems, the same section of break.exp does this:
> 
>   break marker2
>   print marker2 (99)          # GDB stops in the dummy call to marker2
>   bt
>   finish
>   runto_main
> 
> The finish command runs GDB to the dummy breakpoint, which then gets
> deleted, allowing the subsequent runto_main to work as expected.
> 
> I removed the HP-UX conditional and made the regular expressions a bit
> more general.  With these changes, the script expects the bt output to
> look something like this:
> 
>   #0  marker2 (a=99) at ../../../src/gdb/testsuite/gdb.base/break.c:49
>   #1  <function called from gdb>
> 
> or this:
> 
>   #0  marker2 (a=99) at ../../../src/gdb/testsuite/gdb.base/break.c:49
>   #1  ... _sr4export ...
> 
> _sr4export is part of the original code, so I assume it's needed on HP-UX.
> I haven't been able to test that assumption, though.  Does anyone know
> whether it's true?
> 
> Also, I assume that GDB always should display "<function called from gdb>"
> when backtracing through a dummy function.  If that's not true, then this
> patch will cause failures on some systems.
> 
> There are no regressions on i686-pc-linux-gnu or sparc-sun-solaris2.5.1.
> 
> Okay to apply?
> 
> Nick
> 
> [patch follows]
> 
> Index: gdb/testsuite/gdb.base/break.exp
> ===================================================================
> diff -up gdb/testsuite/gdb.base/break.exp gdb/testsuite/gdb.base/break.exp
> --- gdb/testsuite/gdb.base/break.exp    Thu Nov 16 19:28:03 2000
> +++ gdb/testsuite/gdb.base/break.exp    Thu Nov 16 19:27:49 2000
> @@ -577,31 +577,35 @@ gdb_expect {
>  # As long as we're stopped (breakpointed) in a called function,
>  # verify that we can successfully backtrace & such from here.
>  #
> -
> -if [istarget "hppa*-*-hpux*"] then {
> -  send_gdb "bt\n"
> -  gdb_expect {
> -      -re "#0\[ \t\]*$hex in marker2.*:4\[49\]\r\n#1.*_sr4export.*$gdb_prompt $"\
> -            {pass "backtrace while in called function"}
> -      -re "#0\[ \t\]*$hex in marker2.*:4\[49\]\r\n#1.*function called from gdb.*$gdb_prompt $"\
> -
> +# In this and the following test, the _sr4export check apparently is needed
> +# for hppa*-*-hpux.
> +#
> +send_gdb "bt\n"
> +gdb_expect {
> +    -re "#0\[ \t\]*$hex in marker2.*:4\[49\]\r\n#1.*_sr4export.*$gdb_prompt $"\
>              {pass "backtrace while in called function"}
> +    -re "#0\[ \t\]*($hex in )?marker2.*:4\[49\]\r\n#1.*function called from gdb.*$gdb_prompt $"\
> +           {pass "backtrace while in called function"}
>      -re "$gdb_prompt $"\
>              {fail "backtrace while in called function"}
>      timeout {fail "(timeout) backtrace while in called function"}
> -  }
> -  send_gdb "finish\n"
> -  gdb_expect {
> -      -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.* in _sr4export.*$gdb_prompt $"\
> +}
> +
> +# Return from the called function.  For remote targets, it's important to do
> +# this before runto_main, which otherwise may silently stop on the dummy
> +# breakpoint inserted by GDB at the program's entry point.
> +#
> +send_gdb "finish\n"
> +gdb_expect {
> +    -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.* in _sr4export.*$gdb_prompt $"\
>              {pass "finish from called function"}
> -      -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*function called from gdb.*$gdb_prompt $"\
> +    -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*function called from gdb.*$gdb_prompt $"\
>              {pass "finish from called function"}
> -      -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*Value returned.*$gdb_prompt $"\
> +    -re "Run till exit from .*marker2.* at .*4\[49\]\r\n.*Value returned.*$gdb_prompt $"\
>              {pass "finish from called function"}
>      -re "$gdb_prompt $"\
>              {fail "finish from called function"}
>      timeout {fail "(timeout) finish from called function"}
> -  }
>  }
> 
>  # Verify that GDB responds gracefully to a "finish" command with

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]