From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 5C6103876053 for ; Tue, 5 Apr 2022 15:15:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C6103876053 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 235DXCgW016865; Tue, 5 Apr 2022 15:15:15 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0b-001b2d01.pphosted.com with ESMTP id 3f6yv761tn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Apr 2022 15:15:15 +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 235FDAjt003958; Tue, 5 Apr 2022 15:15:15 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma04wdc.us.ibm.com with ESMTP id 3f6e49r6u6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Apr 2022 15:15:15 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 235FFEKO6423200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Apr 2022 15:15:14 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8405EAE068; Tue, 5 Apr 2022 15:15:14 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 38E68AE060; Tue, 5 Apr 2022 15:15:14 +0000 (GMT) Received: from lexx (unknown [9.160.28.151]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 5 Apr 2022 15:15:14 +0000 (GMT) Message-ID: <553238d49ce5aae0e88a6ce0b7dd6afa96931bc6.camel@vnet.ibm.com> Subject: Re: [PATCH, v2] Fix reverse stepping multiple contiguous PC ranges over the line table From: will schmidt To: Luis Machado , gdb-patches@sourceware.org Date: Tue, 05 Apr 2022 10:15:13 -0500 In-Reply-To: <3d467cfa-1844-397c-931b-ffd832fa254f@arm.com> References: <7a429c919395db6ec4642803badca5dbb97bff66.camel@us.ibm.com> <20220331135246.7913-1-luis.machado@arm.com> <3d467cfa-1844-397c-931b-ffd832fa254f@arm.com> 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-ORIG-GUID: Cu92v4l8FH8_foNdamVt5FNsVomxQ29K X-Proofpoint-GUID: Cu92v4l8FH8_foNdamVt5FNsVomxQ29K X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-04-05_04,2022-04-05_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 suspectscore=0 phishscore=0 adultscore=0 mlxscore=0 bulkscore=0 malwarescore=0 impostorscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204050086 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2022 15:15:19 -0000 On Tue, 2022-04-05 at 09:36 +0100, Luis Machado wrote: > On 4/4/22 17:55, will schmidt wrote: > > On Thu, 2022-03-31 at 14:52 +0100, Luis Machado via Gdb-patches > > wrote: > > > v2: > > > - Check if both the line and symtab match for a particular line > > > table entry. > > > > > > -- > > > > > > When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also > > > spotted on > > > the ppc backend), I noticed some failures in gdb.reverse/solib- > > > precsave.exp > > > and gdb.reverse/solib-reverse.exp. > > > > > > The failure happens around the following code: > > > > > > 38 b[1] = shr2(17); /* middle part two */ > > > 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */ > > > 42 shr1 ("message 1\n"); /* shr1 one */ > > > > > > Normal execution: > > > > > > - step from line 38 will land on line 40. > > > - step from line 40 will land on line 42. > > > > > > Reverse execution: > > > > > > - step from line 42 will land on line 40. > > > - step from line 40 will land on line 40. > > > - step from line 40 will land on line 38. > > > > > > The problem here is that line 40 contains two contiguous but > > > distinct > > > PC ranges in the line table, like so: > > > > > > Line 40 - [0x7ec ~ 0x7f4] > > > Line 40 - [0x7f4 ~ 0x7fc] > > > > > > > > > > > I'm not particularly happy with how we go back in the ranges > > > (using "pc - 1"). > > > Feedback would be welcome. > > > > I suppose there could be a loop of some sort that iterates > > backwards to > > a valid line; though I'd think pc - 1 is sufficient? > > > > Yes, it seems to do the job. > > > > Validated on aarch64-linux/Ubuntu 20.04/18.04. Carl Love has > > > verified that it > > > does fix a similar issue on ppc. > > > > > > Ubuntu 18.04 doesn't actually run into these failures because the > > > compiler > > > doesn't generate distinct PC ranges for the same line. > > > > > > I see similar failures on x86_64 in the gdb.reverse tests > > > (gdb.reverse/step-reverse.exp and gdb.reverse/step-reverse.exp). > > > Those are > > > also fixed by this patch, although Carl's testcase doesn't fail > > > for x86_64. > > > > > > There seems to be a corner case where a line table has only one > > > instruction, > > > and while stepping that doesn't take the same path through > > > infrun. I think it > > > needs some more investigation. Therefore this is a tentative > > > patch for now. > > > > Are you (or Carl) continuing to pursue that edge case? > > > > Not at the moment unfortunately. I know that this needs to be handled > in > the fallthrough of process_event_stop_test. Carl's test doesn't seem > to > fail for x86_64 (at least for me). We need to polish the testcase a > bit > more so that we can cover that corner case as well. > > Also, this is more of a RFC at this point. You'll notice some debug > print statement in the patch. It would be nice to turn those into > permanent debug prints, as this code doesn't seem to print too much > detail about what it is doing. OK, thanks. I did notice the debug printfs. Since they were actually using the infrun_debug_printf helper, versus actual printf calls, I assumed they were deliberate and meant for the long term. :-) I wasn't going to nit on the uppercase content of the debug printfs, I figure since they are actually debug for special circumstances the debug was fine as presented. :-) I'm generally a fan of adding more debug output. Thanks -Will