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 8DEF03953829 for ; Fri, 6 May 2022 16:46:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8DEF03953829 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 246FbZGM018337; Fri, 6 May 2022 16:46:38 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3fw5hstr2h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 May 2022 16:46:37 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 246Gh1Hx023291; Fri, 6 May 2022 16:46:37 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3fw5hstr29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 May 2022 16:46:37 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 246GSJLi005597; Fri, 6 May 2022 16:46:36 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma01wdc.us.ibm.com with ESMTP id 3frvra1mg9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 May 2022 16:46:36 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 246Gka7K42271088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 6 May 2022 16:46:36 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 64F1CAE067; Fri, 6 May 2022 16:46:36 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BAF14AE05F; Fri, 6 May 2022 16:46:35 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.152.172]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 6 May 2022 16:46:35 +0000 (GMT) Message-ID: From: Carl Love To: Bruno Larsen , Luis Machado , gdb-patches@sourceware.org Cc: rogealve@br.ibm.com, will_schmidt@vnet.ibm.com Date: Fri, 06 May 2022 09:46:35 -0700 In-Reply-To: <9e420536-01e0-7192-d585-747c52fdf4d5@redhat.com> References: <20220506085506.9184-1-luis.machado@arm.com> <9e420536-01e0-7192-d585-747c52fdf4d5@redhat.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-GUID: 8cof6B5QcZ8OgULngRLR0Z3aempiQsVr X-Proofpoint-ORIG-GUID: GcF9OML0Wdk6uy34qR5ly_kI21DOgLBR Subject: RE: [PATCH, v4] Fix reverse stepping multiple contiguous PC ranges over the line table X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-05-06_04,2022-05-06_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 clxscore=1015 bulkscore=0 priorityscore=1501 mlxlogscore=984 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2205060085 X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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: Fri, 06 May 2022 16:46:42 -0000 Bruno: On Fri, 2022-05-06 at 12:04 -0300, Bruno Larsen wrote: > > >. > > + > > +# The purpose of this test is to create a DWARF line table that > > contains two > > +# or more entries for the same line. When stepping (forwards or > > backwards), > > +# GDB should step over the entire line and not just a particular > > entry in the > > +# line table. > > + > > Could you add a comment here after the copyright blurb explaining why > this testcase exists? Something similar to the find_line_range_start > comment should be enough, jsut so the next unrelated person who looks > at this code in 2 years has some context as to what is going on. OK, updated the comment to say the purpose is to test the find_line_range_start functionality. I did reorganize the comment a bit to make things flow better. Specifically, started with the expected behaviour of GDB followed by testing find_line_range_start to ensure GDB works as expected. > > > +load_lib dwarf.exp > > + > > +# This test can only be run on targets which support DWARF-2 and > > use gas. > > +if {![dwarf2_support]} { > > + unsupported "dwarf2 support required for this test" > > + return 0 > > +} > > + > > +if [get_compiler_info] { > > + return -1 > > +} > > + > > +# The DWARF assembler requires the gcc compiler. > > +if {!$gcc_compiled} { > > + unsupported "gcc is required for this test" > > + return 0 > > +} > > There should probably be a test here for supports_reverse. Or > supports_process_record. I'm not sure what the difference is between > these 2 checks. Yes, I added if ![supports_process_record] test here to make sure the system supports the record and replay. > > > + > > +if { [prepare_for_testing "failed to prepare" ${testfile} \ > > + [list $srcfile $asm_file] {nodebug} ] } { > > + return -1 > > +} > > + > > +if ![runto_main] { > > + return -1 > > +} > > + > > +if [supports_process_record] { > > + # Activate process record/replay > > + gdb_test_no_output "record" "turn on process record" > > +} > since we would have tested above if the target supports > recording/reversing, we should be good to just use record here, > without the if clause. I suggest doing it this way because there is > no point in this whole test if the target doesn't support reverse > execution. Yes, removed the supports_process_record test. > > Will post v5 of the patch for review. Thanks for the input. Carl Love