From: Fernando Nasser <fnasser@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH RFA] gdb.base/finish.exp: Allow finish to stop on call
Date: Wed, 23 May 2001 17:21:00 -0000 [thread overview]
Message-ID: <3B0C5364.11326C70@redhat.com> (raw)
In-Reply-To: <1010519003833.ZM16512@ocotillo.lan>
Kevin Buettner wrote:
>
> On the IA-64, a "finish" won't stop us at the statement after the call
> due to the fact that the "call" instruction isn't the last instruction
> in the call sequence. (The global pointer still needs to be reset.)
> The patch below tweaks the finish_void test to allow for this
> eventuality.
>
> Okay to commit?
>
Nice catch Kevin. Thanks.
Your second pattern needs a small improvement though. As we are
returning to the middle of that source line, the information printed by
GDB will have the address (PC) as well. We must make sure that we test
for that so we can differentiate between returning to the beginning of
the calling line (wrong) and returning to after where the assembler jump
to subroutine was (right). You can test for that without binding to a
specific PC value -- there are several examples around.
After making this change, and testing that it works, of course, you can
commit your patch. Please post the final version for the records.
Thanks again for the fix.
Regards,
Fernando
> * gdb.base/finish.exp (finish_void): Allow "finish" command to
> stop on the call statement as well as the statement after the
> call.
>
> Index: testsuite/gdb.base/finish.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/finish.exp,v
> retrieving revision 1.3
> diff -u -p -r1.3 finish.exp
> --- finish.exp 2001/03/06 08:21:50 1.3
> +++ finish.exp 2001/05/19 00:27:32
> @@ -77,8 +77,15 @@ proc finish_void { } {
> gdb_test "continue" "Breakpoint.* void_func.*" \
> "continue to void_func"
> send_gdb "finish\n"
> + # Some architectures will have one or more instructions after the
> + # call instruction which still is part of the call sequence, so we
> + # must be prepared for a "finish" to show us the void_func call
> + # again as well as the statement after.
> gdb_expect {
> -re ".*void_checkpoint.*$gdb_prompt $" {
> + pass "finish from void_func"
> + }
> + -re ".*call to void_func.*$gdb_prompt $" {
> pass "finish from void_func"
> }
> -re ".*$gdb_prompt $" {
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
next prev parent reply other threads:[~2001-05-23 17:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-18 17:38 Kevin Buettner
2001-05-18 18:24 ` Michael Snyder
2001-05-21 17:27 ` Kevin Buettner
2001-05-23 17:21 ` Fernando Nasser [this message]
2001-05-23 18:53 ` Kevin Buettner
2001-05-23 19:06 ` Fernando Nasser
2001-05-23 19:56 ` Michael Snyder
2001-05-24 6:47 ` Fernando Nasser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B0C5364.11326C70@redhat.com \
--to=fnasser@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox