public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: gdb-patches@sourceware.org, Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: cel@us.ibm.com
Subject: [PATCH] PowerPC, fix test gdb.arch/altivec-regs.exp
Date: Tue, 07 Mar 2023 12:24:41 -0800	[thread overview]
Message-ID: <3201f8986b24647fdf1492d83354b869a207ad97.camel@us.ibm.com> (raw)

GDB maintainers:

The following patch fixes test gdb.arch/altivec-regs.exp.  The issue is
the test sets a breakpoint on the line that it is currently stopped at
and then does a continue to get to the same line to start the test. 
The test assumes GDB will stop at the breakpoint it just set.  However,
GDB runs to the end of the program.  The test is fixed by initializing
a local variable so GDB will stop on the variable initialization.  GDB
then sets and runs to the breakpoint where the test starts.

The issue only seems to occur with some distros, specifically with
RHEL9.  The patch fixes the test so it runs correctly on RHEL 9.

Please let me know if this patch is acceptable for mainline.  Thanks.

                     Carl 
----------------------------------------------------------
PowerPC, fix test gdb.arch/altivec-regs.exp

The test fails on Power 10 with the RHEL9 distro but passes on Ubuntu 22.04.

The test set a the breakpoint in main that stops at line:
a = 9; /* start here */.  The test then sets a break point at the same
line where it wants to start the test and does a continue.  GDB does not
stop again on the same line where it is stopped, but rather continues to
the end of the program.

Initialize variable A to zero so the break on main will stop before setting
a break point on line a = 9; /* start here */.

Make the match on the breakpoint number generic.

Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
and Power 9 with Fedora 36 with no regression failures.
---
 gdb/testsuite/gdb.arch/altivec-regs.c   | 2 +-
 gdb/testsuite/gdb.arch/altivec-regs.exp | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.arch/altivec-regs.c b/gdb/testsuite/gdb.arch/altivec-regs.c
index 1411f15e358..a838b28b9b5 100644
--- a/gdb/testsuite/gdb.arch/altivec-regs.c
+++ b/gdb/testsuite/gdb.arch/altivec-regs.c
@@ -18,7 +18,7 @@ main ()
   vector unsigned int y; 
   vector unsigned int x; 
   vector unsigned int z; 
-  int a;
+  int a = 0;
 
   #ifdef _AIX
   /* On AIX, the debugger cannot access vector registers before they
diff --git a/gdb/testsuite/gdb.arch/altivec-regs.exp b/gdb/testsuite/gdb.arch/altivec-regs.exp
index b771a4df76f..ece207be48e 100644
--- a/gdb/testsuite/gdb.arch/altivec-regs.exp
+++ b/gdb/testsuite/gdb.arch/altivec-regs.exp
@@ -122,7 +122,7 @@ send_gdb "info vector\n"
 gdb_expect_list "info vector" ".*$gdb_prompt $" $pattern_list
 
 gdb_test "break vector_fun" \
- "Breakpoint 2 at.*altivec-regs.c, line \[0-9\]+\\." \
+ "Breakpoint $decimal at.*altivec-regs.c, line \[0-9\]+\\." \
  "set breakpoint at vector_fun"
 
 # Actually it is nuch easier to see these results printed in hex.
@@ -131,7 +131,7 @@ gdb_test "set output-radix 16" \
   "set output radix to hex"
 
 gdb_test "continue" \
-  "Breakpoint 2, vector_fun .a=.0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe., b=.0x1010101, 0x1010101, 0x1010101, 0x1010101.*altivec-regs.c.*vec_splat_u8.2..;" \
+  "Breakpoint $decimal, vector_fun .a=.0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe., b=.0x1010101, 0x1010101, 0x1010101, 0x1010101.*altivec-regs.c.*vec_splat_u8.2..;" \
   "continue to vector_fun"
 
 # Do a next over the assignment to vector 'a'. 
-- 
2.37.2



             reply	other threads:[~2023-03-07 20:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 20:24 Carl Love [this message]
2023-03-08 13:28 ` Ulrich Weigand

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=3201f8986b24647fdf1492d83354b869a207ad97.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /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).