public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: gdb-patches@sourceware.org
Cc: Carl Love <cel@us.ibm.com>, Rogerio Alves <rogealve@br.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Will Schmidt <will_schmidt@vnet.ibm.com>
Subject: [PATCH] Improve forward progress test in gdb.python/python.exp
Date: Fri, 06 Aug 2021 15:40:58 -0700	[thread overview]
Message-ID: <4fd73f34dd7db949309de791ea5514890a0f9139.camel@us.ibm.com> (raw)

GDB maintainers:

The current gdb.python/python.exp test fails on powerpc.  The test
checks to see if the source code line for the function call is less
than the line number after the function call.  The issue on powerpc is
the assembly instructions for the branch and the NOP following the
branch map to the same source code line.  

An additional check of the PC before and after the function call is
done if the line number check fails.  This additional check takes care
of the case where the call and return locations map to the same source
code line.

The patch has been run on Powerpc with no regressions.

Please let me know if the patch is acceptable.  Thanks.

                          Carl Love


--------------------------------------------------------

The test steps into func2 and than does an up to get back to the previous
frame. The test checks that the line number you are at after the up command
is greater than the line where the function was called from. The
assembly/codegen for the powerpc target includes a NOP after the
branch-link.

func2 (); /* Break at func2 call site. /
10000694: 59 00 00 48 bl 100006ec
10000698: 00 00 00 60 nop
return 0; / Break to end. */
1000069c: 00 00 20 39 li r9,0

The PC at the instruction following the branch-link is 0x10000698 which
GDB.find_pc_line() maps to the same line number as the bl instruction.
GDB did move past the branch-link location thus making forward progress.

The following proposed fix adds an additional PC check to see if forward
progress was made in the case where the original line test fails.
---
 gdb/testsuite/gdb.python/python.exp | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.python/python.exp b/gdb/testsuite/gdb.python/python.exp
index d9fd60f3dd4..4472ed0994f 100644
--- a/gdb/testsuite/gdb.python/python.exp
+++ b/gdb/testsuite/gdb.python/python.exp
@@ -496,12 +496,32 @@ if ![runto_main] then {
 runto [gdb_get_line_number "Break at func2 call site."]
 
 gdb_py_test_silent_cmd "python line = gdb.selected_frame().find_sal().line" "Get line number of func2 call site" 1
+
+gdb_py_test_silent_cmd "python pc_call = gdb.selected_frame().pc()" "Get pc at return from func2 location" 1
+
 gdb_test "python print (gdb.find_pc_line(gdb.selected_frame().pc()).line == line)" "True" "test find_pc_line at func2 call site"
 
 gdb_py_test_silent_cmd "step" "Step into func2" 1
 gdb_py_test_silent_cmd "up" "Step out of func2" 1
 
-gdb_test "python print (gdb.find_pc_line(gdb.selected_frame().pc()).line > line)" "True" "test find_pc_line with resume address"
+gdb_py_test_silent_cmd "python pc_rtn = gdb.selected_frame().pc()" "Get pc at func2 return site" 1
+
+# The point of the following test is to see if gdb has advanced past the
+# location where the branch to a function was made.
+set test_name "test find_pc_line with resume address"
+
+gdb_test_multiple "python print (gdb.find_pc_line(gdb.selected_frame().pc()).line > line)" $test_name {
+    -re "True.*" {
+	pass $test_name
+    }
+    -re "False.*" {
+	# The instruction at the call-return site may also be associated with
+	# the same line that contained the branch. For example, PPC64 puts a
+	# NOP after the branch to function.  Check if the frame PC has
+	# advanced past the call location.
+	gdb_test "python print (pc_rtn > pc_call)" "True" "test pc_rtn greater then pc_call"
+    }
+}
 
 gdb_test_no_output "set variable \$cvar1 = 23" "set convenience variable"
 gdb_test "python print(gdb.convenience_variable('cvar1'))" "23"
-- 
2.17.1



             reply	other threads:[~2021-08-06 22:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 22:40 Carl Love [this message]
2021-08-09  9:45 ` Andrew Burgess
2021-08-09 15:54   ` Carl Love
2021-08-11 15:58     ` Andrew Burgess
2021-08-11 19:14       ` Carl Love
2021-08-12  9:08         ` Andrew Burgess

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=4fd73f34dd7db949309de791ea5514890a0f9139.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=rogealve@br.ibm.com \
    --cc=will_schmidt@vnet.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).