From: Tom de Vries <tdevries@suse.de>
To: Carl Love <cel@us.ibm.com>, gdb-patches@sourceware.org
Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
Tom Tromey <tom@tromey.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 21:46:23 +0100 [thread overview]
Message-ID: <c9cb2924-5d88-70b8-8a94-c31781f85360@suse.de> (raw)
In-Reply-To: <c8491375ebcaf155d3a68214c88db3bd5632387d.camel@us.ibm.com>
On 11/28/22 20:55, Carl Love wrote:
> 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.
Yeah, I known what you mean :)
> I tried your suggested fix. GDB didn't take the parenthesis around
> \\.$decimal.
Hmm, that sounds unexpected to me. Can you post the exact patch that
didn't work for you? Note that the regexp uses the same construct in
the "($hex in )?" bit.
> 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.
>
It doesn't work, as expected, because the output is:
...
Breakpoint 1, foo_o224_021.child1.child2 (s=...) at
/home/vries/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.ada/out_of_line_in_inlined/foo_o224_021.adb:24^M
...
and $decimal\\.$decimal? does not match "1".
Thanks,
- Tom
> 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)?"
next prev parent reply other threads:[~2022-11-28 20:46 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
2022-11-28 20:46 ` Tom de Vries [this message]
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=c9cb2924-5d88-70b8-8a94-c31781f85360@suse.de \
--to=tdevries@suse.de \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
--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).