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>
Subject: Re: [pushed] [gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le
Date: Mon, 28 Nov 2022 18:17:00 +0100	[thread overview]
Message-ID: <7d3590e8-3ab8-58d2-00d2-ff964a16a20c@suse.de> (raw)
In-Reply-To: <2f7fe4da206abe6f0a3bf9b016bda22fa20e5a4c.camel@us.ibm.com>

On 11/28/22 18:13, Carl Love wrote:
> Tom:
> 
> On Mon, 2022-11-28 at 14:23 +0100, Tom de Vries wrote:
>> On powerpc64le-linux, I run into:
>> ...
>> (gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit
>> step^M
>> 28      { /* first-retry */^M
>> (gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
>> ...
>>
>> It's a bit easier to understand what happens if we do a full stepping
>> session:
>> ...
>> Temporary breakpoint 1, main ()
>>      at solib-intra-step-main.c:23
>> 23        shlib_first ();
>> (gdb) step
>> shlib_first () at solib-intra-step-lib.c:29
>> 29        shlib_second (0); /* first-hit */
>> (gdb) step
>> 28      { /* first-retry */
>> (gdb) step
>> 29        shlib_second (0); /* first-hit */
>> (gdb) step
>> shlib_second (dummy=0)
>>      at solib-intra-step-lib.c:23
>> 23        abort (); /* second-hit */
>> ...
>> and compare that to the line info:
>> ...
>> CU: solib-intra-step-lib.c:
>> File name                    Line number    Starting
>> address    View    Stmt
>> solib-intra-step-
>> lib.c                22               0x710               x
>> solib-intra-step-
>> lib.c                23               0x724               x
>> solib-intra-step-
>> lib.c                28               0x740               x
>> solib-intra-step-
>> lib.c                29               0x74c               x
>> solib-intra-step-
>> lib.c                28               0x750               x
>> solib-intra-step-
>> lib.c                29               0x758               x
>> solib-intra-step-
>> lib.c                30               0x760               x
>> solib-intra-step-lib.c                 -               0x77c
>> ...
>>
>> So we step from line 29 to line 28, and back to line 29, which is
>> behaviour
>> that matches the line table.  The peculiar order is due to using
>> optimization.
>> The problem is that the test-case doesn't expect this order.
>>
>> Fix this by allowing this order in the test-case.
>>
>> Tested on powerpc64le-linux.
>>
>> PR testsuite/29792
>> Bug:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=29792
>>   
>> ---
>>   gdb/testsuite/gdb.opt/solib-intra-step.exp | 19 +++++++++++++++++++
>>   1 file changed, 19 insertions(+)
>>
>> diff --git a/gdb/testsuite/gdb.opt/solib-intra-step.exp
>> b/gdb/testsuite/gdb.opt/solib-intra-step.exp
>> index 0acda6594c5..e803a7db14d 100644
>> --- a/gdb/testsuite/gdb.opt/solib-intra-step.exp
>> +++ b/gdb/testsuite/gdb.opt/solib-intra-step.exp
>> @@ -58,16 +58,35 @@ gdb_test_multiple "step" $test {
>>       }
>>   }
>>   
>> +set in_second 0
>>   set test "second-hit"
>>   gdb_test_multiple "step" $test {
>> +    -re -wrap " first-retry .*" {
>> +	if { $in_second } {
>> +	    fail $gdb_test_name
>> +	} else {
>> +	    send_gdb "step\n"
>> +	    exp_continue
>> +	}
>> +    }
>> +    -re -wrap " first-hit .*" {
>> +	if { $in_second } {
>> +	    fail $gdb_test_name
>> +	} else {
>> +	    send_gdb "step\n"
>> +	    exp_continue
>> +	}
>> +    }
>>       -re -wrap " second-hit .*" {
>>   	pass $gdb_test_name
>>       }
>>       -re -wrap " second-retry .*" {
>> +	set in_second 1
>>   	send_gdb "step\n"
>>   	exp_continue
>>       }
>>       -re -wrap "get_pc_thunk.*" {
>> +	set in_second 1
>>   	send_gdb "step\n"
>>   	exp_continue
>>       }
>>
>> base-commit: ddff2a2dea5261789e1f281f3ee1b33dd5fd8892
> 
> I ran the test with and without the commit on my Power 10 and Power 9
> systems.  I did not see the issue on either system before or after the
> fix.  I am guessing there is probably a system configuration difference
> between my systems and yours.  The fix looks fine to me in that it
> doesn't break anything on my systems.  But I am unable to reproduce the
> reported failure.
> 
> 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

Hi Carl,

my system (openSUSE Leap 15.4) has system gcc 7.5.0, so my guess is that 
that is the relevant system configuration difference.

Thanks,
- Tom

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

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 13:23 Tom de Vries
2022-11-28 17:13 ` Carl Love
2022-11-28 17:17   ` Tom de Vries [this message]

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=7d3590e8-3ab8-58d2-00d2-ff964a16a20c@suse.de \
    --to=tdevries@suse.de \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.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).