From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 8E1BC3858D39 for ; Mon, 27 Mar 2023 23:59:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8E1BC3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32RN9qWS005844; Mon, 27 Mar 2023 23:59:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version : subject; s=pp1; bh=fExQ8nULX0TMLGPN2Tkqd7KHC8V67kATpBg6r6BsKSA=; b=keSA6VGwCEwDDUmLbwIqhX31yjEkXd/S0mClBZsBOIuWdPuPZi+hj7sEvBAaWmkjTY8F Quas26ZGA6nssyh0t8Nzhz5HURV6YBv3TuEKIXfDb7vzgdtAWFG3/WppK7tLd+MEZ6kY da4uhVs+pO0c1QXw0eog+rp+kUF8wQ+u/LjVbXVk9TmcQ7AmKmfDObKwUThmtYKpJ6jM eXTWX7uHvXY4h0UzIIqiNKlkXEnyKIQPiYO5tjC+oYaxQ7FqVz/R8t0t/TfgBmS1+ccx P6DeXJKsfumhL+WT5J09HWCfRtUhXgwXkPiYcPg+zSoXPiVudaTPGkRZNl/v+hjEfHwU iQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3pkh3bnevt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2023 23:59:53 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 32RNxLoK001099; Mon, 27 Mar 2023 23:59:52 GMT Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3pkh3bnev7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2023 23:59:52 +0000 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 32RLWcq9030701; Mon, 27 Mar 2023 23:59:51 GMT Received: from smtprelay03.wdc07v.mail.ibm.com ([9.208.129.113]) by ppma02wdc.us.ibm.com (PPS) with ESMTPS id 3phrk7drd6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Mar 2023 23:59:51 +0000 Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay03.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 32RNxnsW30802602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Mar 2023 23:59:50 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B02AC58056; Mon, 27 Mar 2023 23:59:49 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2ADDF58052; Mon, 27 Mar 2023 23:59:49 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.103.7]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTP; Mon, 27 Mar 2023 23:59:49 +0000 (GMT) Message-ID: <60c362e6dadd05754907af5f10e6f3c0423e1901.camel@us.ibm.com> From: Carl Love To: Simon Marchi , Tom de Vries , Ulrich Weigand , "gdb-patches@sourceware.org" , Bruno Larsen , "pedro@palves.net" Cc: cel@us.ibm.com Date: Mon, 27 Mar 2023 16:59:48 -0700 In-Reply-To: <9cf51eb9-c731-6f42-ab2b-a37048f25d12@simark.ca> References: <59417813-eb4a-baf8-4e5d-e225d6732f71@suse.de> <7a494157-494f-6adf-d533-bf373b0f054f@redhat.com> <71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com> <15864a6b87b25c93e99a28149f23138267735f2a.camel@us.ibm.com> <041f62e9f26fd4a536bc90c34f072985582e6237.camel@de.ibm.com> <46c2c756475ba5923d7eed97996632a08285dd42.camel@us.ibm.com> <65861786-069e-53a1-ca17-a525b6629c95@suse.de> <5be0c849abeef84d34a6ff255fb2705ca5dcb035.camel@us.ibm.com> <5e60a837-b21c-011f-c94e-e8bbf7645c5d@simark.ca> <7639de48695d52a806627b0a91979ad2e5fd9b42.camel@us.ibm.com> <9cf51eb9-c731-6f42-ab2b-a37048f25d12@simark.ca> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-GUID: BmQZ4fYzg1S9S4avIWbsV5iCnEsTu8Ag X-Proofpoint-ORIG-GUID: tN_sIFonpBJQ-HtbOPzET9Jpc2GEhiJV Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 1 URL was un-rewritten MIME-Version: 1.0 Subject: RE: [PATCH 2/2 ] PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-24_11,2023-03-27_02,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 spamscore=0 phishscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2303270186 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_MANYTO,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Simon: On Sat, 2023-03-25 at 08:39 -0400, Simon Marchi wrote: > > > > > Yes, there was a regression failure. The following was committed > > to > > fix the reported regression issues. > > > > https://sourceware.org/pipermail/gdb-patches/2023-March/198139.html > > I also saw these regressions, but they are fixed (by that > commit). This > seems like a different thing. > > > Are you testing with this fix? > > Yes, and I just tried with today's master, same thing. > > > I don't normally run the tests with --target_board=native-gdbserver > > but > > I did try that and it seemed to work for me. Note I had to also > > specify GDBFLAGS to get the test to run. Specifically, I used the > > command: > > > > make check TESTS="gdb.reverse/finish-reverse- > > next.exp" RUNTESTFLAGS="GDBFLAGS=' ' --target_board=native- > > gdbserver " > > That's odd, I never had to do that thing with GDBFLAGS. What happens > when you don't specify it? When I run on Power 10 without GDBFLAGS I get the message: make check TESTS="gdb.reverse/finish-reverse-next.exp" RUNTESTFLAGS=" --target_board=native-gdbserver " ERROR: tcl error sourcing board description file for target /home.../gdb/testsuite/boards/gdbserver-base.exp. can't read "GDBFLAGS": no such variable can't read "GDBFLAGS": no such variable while executing "set GDBFLAGS "${GDBFLAGS} -iex \"set auto-connect-native-target off\""" (file "/home.../gdb/testsuite/boards/gdbserver-base.exp" line 35) invoked from within "source /home.../gdb/testsuite/boards/gdbserver-base.exp" ("uplevel" body line 1) invoked from within "uplevel #0 source /home/.../gdb/testsuite/boards/gdbserver-base.exp" invoked from within "catch "uplevel #0 source $filename" error" make[5]: *** [Makefile:1829: check-DEJAGNU] Error 1 > > For reference, here's an example failure: > > 147 reverse-next^M > 148 81 b = 5;^M > 149 (gdb) FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 > LEP from function body > 150 reverse-next^M > 151 80 a = 1;^M > 152 (gdb) FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 > at b = 5, from function body You didn't mention what platform you are running on, but I am guessing X86. I created a little run script to run the test with and without the --target-board argument on Power 10. Here is my script. more check-reverse echo " " echo reverse.exp rm testsuite/gdb.log make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.reverse/finish-reverse-next.exp ' > out-reverse-next grep "of expected passes" testsuite/gdb.log grep "of unexpected failures" testsuite/gdb.log mv testsuite/gdb.log testsuite/gdb.log-reverse-next echo " " echo reverse.exp rm testsuite/gdb.log make check TESTS="gdb.reverse/finish-reverse-next.exp" RUNTESTFLAGS="GDBFLAGS=' ' --target_board=native-gdbserver " > out-reverse-next-gdbserver grep "of expected passes" testsuite/gdb.log grep "of unexpected failures" testsuite/gdb.log mv testsuite/gdb.log testsuite/gdb.log-reverse-next-gdbserver So, assuming you are on X86, I copied the script to my X86 box and tried it out there as well. I ran the script in the top of the build directory. For the first test without --target_board I get the results: Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /.../gdb/testsuite/config/unix.exp as tool-and-target-specific interface file. Running /.../binutils-gdb-finish-precsave-PPC-Only/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ... === gdb Summary === # of expected passes 40 gdb version 14.0.50.20230324-git -nw -nx -iex "set height 0" -iex "set width 0" === gdb Summary === # of expected passes 40 gdb version 14.0.50.20230324-git -nw -nx -iex "set height 0" -iex "set width 0" The second test with the --target_board I get a number of failures and never actually get to run the finish-reverse-next test. The output I see is: Running target native-gdbserver Using /usr/share/dejagnu/baseboards/native-gdbserver.exp as board description file for target. Using /home/carll/GDB/binutils-gdb-finish-precsave-PPC-Only/gprofng/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/carll/GDB/binutils-gdb-finish-precsave-PPC-Only/gprofng/testsuite/gprofng.display/display.exp ... ERROR: comparison of results in mttest failed ERROR: comparison of results in mttest failed ERROR: comparison of results in synprog failed ERROR: comparison of results in synprog failed === gprofng Summary === # of unresolved testcases 4 # of unsupported tests 1 make[4]: Leaving directory '/home/.../gprofng' make[3]: Leaving directory '/home/.../gprofng' make[2]: Leaving directory '/home/.../gprofng' make[1]: Leaving directory '/home/...' So, tried changing the paths in the script from gdb/testscript to testscript and then ran the script in the subdirectory gdb. When I do that, I get the same results for the first test as I saw befor. Now, the second test with --target_board runs and I get the following output: ... Using /home/.../binutils-gdb-finish-precsave-PPC-Only/gdb/testsuite/boards/../boards/gdbserver-base.exp as board de scription file for target. Using /home/.../binutils-gdb-finish-precsave-PPC-Only/gdb/testsuite/boards/../boards/local-board.exp as board description file for target. Using /home/carll/GDB/build-finish-precsave-PPC-Only/gdb/testsuite/../../../binutils-gdb-finish-precsave-PPC-Only/gdb/testsuite/config/gdbserver.exp as tool-and-target-specifi c interface file. Running /home/carll/GDB/build-finish-precsave-PPC-Only/gdb/testsuite/../../../binutils-gdb-finish-precsave-PPC-Only/gdb/testsuite/gdb.reverse/finish-reverse-next.exp ... FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 GEP call from function body FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 50 from function body === gdb Summary === # of expected passes 36 # of unexpected failures 4 which appears to match the failures you saw. Why the --target-board argument seems to make a difference is a mystery to me at this point!! I can see what what happens... So, when you do a reverse-finish, gdb stops at the branch instruction for the function call. Then when you do a reverse-next and gdb stops at the beginning of the same source code line. This is the expected behavior for gdb per the discussion we had a few months ago. Hence in the test file we have: # The reverse-finish command should stop on the function call instruction # which is the last instruction in the source code line. A reverse-next # instruction should then stop at the first instruction in the same source # code line. Another revers-next instruction stops at the previous source # code line. gdb_test "reverse-finish" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \ "reverse-finish function1 LEP call from function body" gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \ "reverse next 1 LEP from function body" gdb_test "reverse-next" ".*b = 5;.*" \ "reverse next 2 at b = 5, from function body" The test is looking to see that it is at source line function1 (a, b) after both reverse-finish and the reverse-next commands. Looking in the output file for the run with and without the --target- board on X86, we see: without the target board specified: step function1 (a=1, b=5) at /home/carll/.../gdb/testsuite/gdb.reverse/finish-reverse-next.c:51 51 int ret = 0; (gdb) PASS: gdb.reverse/finish-reverse-next.exp: step test 1 reverse-finish Run back to call of #0 function1 (a=1, b=5) at /home/carll/..../gdb/testsuite/gdb.reverse/finish-reverse-next.c:51 0x00005555555551cb in main (argc=1, argv=0x7fffffffde88) at /home/carll/.../gdb/testsuite/gdb.reverse/finish-reverse-next.c:83^M 83 function1 (a, b); // CALL VIA LEP (gdb) PASS: gdb.reverse/finish-reverse-next.exp: reverse-finish function1 LEP call from function body reverse-next 83 function1 (a, b); // CALL VIA LEP (gdb) PASS: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body reverse-next 81 b = 5; reverse-continue Continuing. No more reverse-execution history. We see the reverse-finish and the reverse-next both stop at function1 (a, b) as expected. But with --target-board, we see: step function1 (a=1, b=5) at /home/carll/..../gdb/testsuite/gdb.reverse/finish-reverse-next.c:51 51 int ret = 0; (gdb) PASS: gdb.reverse/finish-reverse-next.exp: step test 1 reverse-finish Run back to call of #0 function1 (a=1, b=5) at /home/carll/..../gdb/testsuite/gdb.reverse/finish-reverse-next.c:51 main (argc=1, argv=0x7fffffffde88) at /home/carll/.../gdb/testsuite/gdb.reverse/finish-reverse-next.c:83 83 function1 (a, b); // CALL VIA LEP (gdb) PASS: gdb.reverse/finish-reverse-next.exp: reverse-finish function1 LEP call from function body reverse-next 81 b = 5; (gdb) FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 1 LEP from function body reverse-next 80 a = 1; (gdb) FAIL: gdb.reverse/finish-reverse-next.exp: reverse next 2 at b = 5, from function body reverse-continue Continuing. It appears the reverse-finish stopped at the beginning of the source line, not the function call as expected, because the reverse-next stops at the previous source line not the same source line as expected. I think it would only do that if GDB was at the beginning of the source line after the reverse-finish command is done. The issue "appears to be" that the reverse-finish command behaves differently with the -- target_board??? I am at a loss as to why using gdbserver causes this change in the behavior of the test. Unfortunately, I have never looked at how gdbserver works so I don't know what the issue might be. I tried rewinding my gdb tree on X86 to the commit commit 334d405c2ac395fca67b952affb20893002d969f (HEAD) Author: Carl Love Date: Wed Mar 1 11:45:43 2023 -0500 Move step_until procedure .... which is the commit before the fix for the reverse-finish command on Power10. Note, the finish-reverse-next is a new test that is added with the Power 10 reverse-finish command fix. I had to make a copy of finish-reverse-next.c and finish-reverse-next.exp before rewinding the source tree and restoring them after the rewind. I rebuilt gdb without the PowerPC fix. When I run my script I see the exact same behavior on X86, i.e. the first test works fine, the second test fails. So, it looks to me like the issue is independent of the changes made in my commit for Power10. It would probably be good if you can try to reproduce the failure without the Power10 fix. Note, you do need the patch to move the step_until proceedure so when you restore the test it will work. The test is dependent on that commit. Let me know if you can verify the test fails without the Power10 fix and with --target_board. When I run the above script on Power 10, the first test runs fine and is the only test that is run. The second test results in running a whole bunch of tests in addition to finish-reverse-next. I have to search thru the log file to find where the test ran. No errors are reported for the finish-reverse-next test. But I do see errors in other tests. Actually, the output looks like what I get when I run "make check". I looked to see if I could find an error about the arguments that would explain why the test "appears" to ignore the request to run one test and runs what appears to be everything. I don't see reported errors or warnings. I also tried moving the script to the gdb build directory/gdb, like what I did on X86, and tweaked the paths in the script. Again, the first test runs just fine and appears to be the only test that is run. The second test seems to actually run all of the tests again. When I look in the log file, again I can see where finish-reverse-next ran and doesn't appear to generate any errors but I am seeing all these other tests that ran. In summary, there seems to be an issue with using the --target_board argument. On X86, the reverse-finish command seems to work a little different with and without the --target-board command. This is independent of the Power 10 reverse-finish patch. On Power 10, the use of the --target_board option seems to cause all tests to run not just the one requested. Maybe there is something wrong with the make command in the test file that explains the behavior on Power 10?? Unfortunately, I have not worked on gdbserver so I really have no idea what is going on. Carl