From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 3F85E3858C52 for ; Mon, 28 Nov 2022 21:33:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F85E3858C52 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 (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2ASJhIGt032401; Mon, 28 Nov 2022 21:33:26 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 : mime-version : content-transfer-encoding : subject; s=pp1; bh=ULWCiP2+kOqeohSlghbsm7xkDaiPDxgMIXN5qbTenFE=; b=ePu9ZmRwpcHzqMekc9nrAPjAJg7vcxSf0tzKYXk3IvTqQrPlTq2+uxnG0Ipin2Kvx2+L Igp4Fyoaq5B5aXpuSC8P7fJUCqedHV4wZsRBNCV9POOfwXVsJEjWLt74YKjJX6fbLit6 Zy4ghPSDrSfdlf3Pv7o6qs/LCnFgBnwgmEkz3dTOjyrnKkgvSO8USewYj1VAffWkgLg7 gcGLrkvKkpizJJFrSYZk5KJEZ+f/NlBXDsFVfN9DMq4BnTsi/5/8iJvwG65jS9rT6njt bNdn1PEvS5YDjrTVWVZ3I2Jp928dH5BjVa0XB2bevnCjERxeA7G6fFPnjzEe8Agh+rLD /w== Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m53cwad0g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 21:33:26 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2ASLLDNs005656; Mon, 28 Nov 2022 21:33:25 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma04wdc.us.ibm.com with ESMTP id 3m3ae9g5a5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 21:33:25 +0000 Received: from smtpav04.wdc07v.mail.ibm.com ([9.208.128.116]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2ASLXOPl1966734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Nov 2022 21:33:25 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 608EB58058; Mon, 28 Nov 2022 21:33:24 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A2A6758054; Mon, 28 Nov 2022 21:33:23 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.52.7]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Mon, 28 Nov 2022 21:33:23 +0000 (GMT) Message-ID: <16e21f1bc616ee23a1f89ecc7fe37a92bdaa9223.camel@us.ibm.com> From: Carl Love To: Tom de Vries , gdb-patches@sourceware.org Cc: Ulrich Weigand , Tom Tromey , Will Schmidt , cel@us.ibm.com Date: Mon, 28 Nov 2022 13:33:23 -0800 In-Reply-To: References: <20221128162134.20424-1-tdevries@suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: CBVHvF8-cPnn78ZTICA4nOb8xbMqt9ds X-Proofpoint-ORIG-GUID: CBVHvF8-cPnn78ZTICA4nOb8xbMqt9ds Subject: RE: [pushed] [gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp for ppc64le X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-28_17,2022-11-28_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 impostorscore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 clxscore=1015 phishscore=0 priorityscore=1501 adultscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211280154 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Tom: On Mon, 2022-11-28 at 21:46 +0100, Tom de Vries wrote: > 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_o > > > > 224_ > > > > 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_o > > > > 224_ > > > > 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". > Digging around looking for the definition of $decimal, I ran into: # A regular expression that matches a breakpoint hit with a breakpoint # having several code locations. set bkptno_num_re "$decimal\\.$decimal" in lib/gdb.exp. I tried changing the patch to 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..ca3798ea9db 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 $bkptno_num_re, ($hex in )?foo_o224_021\\.child1\\.child2 \\(s=\\.\\.\\.\\).*" \ "run to foo_o224_021.child1.child2" set opt_addr_in "($hex in)?" That seems to work on Power 10. See if that works for you. Carl