public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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)?"

  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).