public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Tom Tromey <tom@tromey.com>,
	cel@us.ibm.com, Will Schmidt <will_schmidt@vnet.ibm.com>
Subject: RE: [pushed] [gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp for ppc64le
Date: Mon, 28 Nov 2022 11:55:59 -0800	[thread overview]
Message-ID: <c8491375ebcaf155d3a68214c88db3bd5632387d.camel@us.ibm.com> (raw)
In-Reply-To: <de636dae-c2ae-0240-c54e-e994cef3e071@suse.de>

Tom:

On Mon, 2022-11-28 at 19:08 +0100, Tom de Vries wrote:
> On 11/28/22 18:45, Carl Love wrote:
> > Tom:
> > 
> > 
> > On Mon, 2022-11-28 at 17:21 +0100, Tom de Vries wrote:
> > > On powerpc64le-linux, with test-case
> > > gdb.ada/out_of_line_in_inlined.exp I run
> > > into:
> > > ...
> > > (gdb) run ^M
> > > Starting program: foo_o224_021-all ^M
> > > ^M
> > > Breakpoint 1, 0x0000000010002f48 in foo_o224_021.child1.child2
> > > (s=...) at \
> > >    foo_o224_021.adb:24^M
> > > 24              function Child2 (S : String) return Boolean is --
> > > STOP^M
> > > (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
> > >    run to foo_o224_021.child1.child2
> > > ...
> > > 
> > > The breakpoint is correctly set at the local entry point, and
> > > given
> > > that the
> > > local entry point doesn't correspond to a line number entry, the
> > > instruction
> > > address of the breakpoint is shown.
> > > 
> > > The problem is that test-case doesn't expect the breakpoint
> > > address.
> > > 
> > > Fix this by allowing the breakpoint address to occur.
> > > 
> > > Tested on powerpc64le-linux.
> > > ---
> > >   gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
> > > b/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
> > > index 4bdb4decaaf..621b04e179b 100644
> > > --- a/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
> > > +++ b/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
> > > @@ -34,7 +34,7 @@ foreach_with_prefix scenario {all minimal} {
> > > 
> > >       gdb_run_cmd
> > >       gdb_test "" \
> > > -	"Breakpoint $decimal, foo_o224_021\\.child1\\.child2
> > > \\(s=\\.\\.\\.\\).*" \
> > > +	"Breakpoint $decimal, ($hex in )?foo_o224_021\\.child1\\.child2
> > > \\(s=\\.\\.\\.\\).*" \
> > >   	"run to foo_o224_021.child1.child2"
> > > 
> > >       set opt_addr_in "($hex in)?"
> > > 
> > > base-commit: 76cd77dc729b03d6b33c683323594479e33a3f9a
> > 
> > The commit fixes the two test failures when run on my Power 9
> > box.  The
> > test runs without any errors on Power 9 with the fix.
> > 
> > However, with the commit to fix the test on Power 10, I see the
> > following failures:
> > 
> > (gdb) run
> > Starting program: /home/carll/GDB/build-
> > test/gdb/testsuite/outputs/gdb.ada/out_of_line_in_inlined/foo_o224_
> > 021-all
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > 
> > Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at
> > /home/carll/GDB/binutils-gdb-
> > test/gdb/testsuite/gdb.ada/out_of_line_\
> > in_inlined/foo_o224_021.adb:27
> > 27                      Do_Nothing (C);
> > (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: run
> > to foo_o224_021.child1.child2
> > 
> > ...
> > 
> > Breakpoint 1 at 0x10011870: foo_o224_021.child1.child2. (3
> > locations)
> > (gdb) run
> > Starting program: /home/carll/GDB/build-
> > test/gdb/testsuite/outputs/gdb.ada/out_of_line_in_inlined/foo_o224_
> > 021-minimal
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > 
> > Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at
> > /home/carll/GDB/binutils-gdb-
> > test/gdb/testsuite/gdb.ada/out_of_line_\
> > in_inlined/foo_o224_021.adb:27
> > 27                      Do_Nothing (C);
> > (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=minimal:
> > run to foo_o224_021.child1.child2
> > 
> > I backed the gdb tree up to the previous commit on Power 10 with
> > the command:
> > 
> >   git checkout af31506c31a59a6edbb13498d6075fa704b801cd
> > 
> > and re-ran the tests.  I see the same two failures.  These failures
> > appear to be different than the ones that Tom reported and fixed
> > with
> > the commit.
> > 
> >  From discussion of previous test fixes, there may be a system
> > configuration difference here:
> > 
> > My Power 10 system:   Fedora release 36 (Thirty Six),  gcc (GCC)
> > 12.2.1
> > 20220819 (Red Hat 12.2.1-2)
> > 
> > Power 9 system:   Ubuntu 20.04.5 LTS,  gcc (Ubuntu 9.4.0-
> > 1ubuntu1~20.04.1) 9.4.0
> > 
> >  From what Tom reported on another test, he is running on (openSUSE
> > Leap
> > 15.4) has system gcc 7.5.0.
> > 
> 
> Hi Carl,
> 
> thanks for looking into this.
> 
> AFAICT, the FAIL is due to the "1.1" rather than "1" for the
> breakpoint.
> 
> So apparently, the compiler optimizes a bit more, resulting in two 
> breakpoints instead of one.
> 
> So, this looks like an independent issue, and I think it could be
> fixed 
> by just accepting the 1.1, by something like replacing "$decimal"
> with 
> "$decimal(\\.$decimal)?".
> 
> Thanks,
> - Tom

Thanks for the help.  I hadn't had time yet to dig into it before
posting the failure.  Trying to do too many things all at the same
time.

I tried your suggested fix.  GDB didn't take the parenthesis around
\\.$decimal.  I made the change   $decimal\\.$decimal?  and that seemed
to work on my system.  I tried the test on my X86 box but it is not
supported.  Looks like the system doesn't have the ada compiler
installed.

Can you verify that the change works on your system and if the patch
looks ok.  Thanks.

                   Carl
---------------------------------------------------------
Additional Fix for gdb.ada/out_of_line_in_inlined.exp for ppc64le

The command to set the breakpoing on foo_o224_021.child1.child2 with
Power 10, Fedora release 36 (Thirty Six) gives the following output:

  (gdb) break foo_o224_021.child1.child2^M
  Breakpoint 1 at 0x10011870: foo_o224_021.child1.child2. (3 locations)
  (gdb) run
  Starting program: ...gdb.ada/out_of_line_in_inlined/foo_o224_021-all
  Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".

  Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at ...gdb.ada/out_of_line_in_inlined/foo_o224_021.adb:27^M
  27                      Do_Nothing (C);
  (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: run to foo_o224_021.child1.child2
bt

The issue appears to be that gdb prints the breakpoint number as 1.1
instead of the expected value of 1.  It appears this is due to a compile
optimization resulting in two breakpoints.

This patch fixes the issue by accepting both breakpoint numbers.

This patch has been tested on Power 10.
---
 gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp b/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
index 621b04e179b..da80a4f7dd9 100644
--- a/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
+++ b/gdb/testsuite/gdb.ada/out_of_line_in_inlined.exp
@@ -34,7 +34,7 @@ foreach_with_prefix scenario {all minimal} {
 
     gdb_run_cmd
     gdb_test "" \
-	"Breakpoint $decimal, ($hex in )?foo_o224_021\\.child1\\.child2 \\(s=\\.\\.\\.\\).*" \
+	"Breakpoint $decimal\\.$decimal?, ($hex in )?foo_o224_021\\.child1\\.child2 \\(s=\\.\\.\\.\\).*" \
 	"run to foo_o224_021.child1.child2"
 
     set opt_addr_in "($hex in)?"
-- 
2.37.2





  reply	other threads:[~2022-11-28 19:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 16:21 Tom de Vries
2022-11-28 17:45 ` Carl Love
2022-11-28 18:08   ` Tom de Vries
2022-11-28 19:55     ` Carl Love [this message]
2022-11-28 20:46       ` Tom de Vries
2022-11-28 21:07         ` Carl Love
2022-11-28 21:31           ` Tom de Vries
2022-11-28 21:44             ` Carl Love
2022-11-28 22:09               ` Tom de Vries
2022-11-28 23:01                 ` Carl Love
2022-11-29  7:24                   ` Tom de Vries
2022-11-28 21:33         ` Carl Love

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=c8491375ebcaf155d3a68214c88db3bd5632387d.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    --cc=tom@tromey.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).