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 C19E43851C1C for ; Fri, 2 Jul 2021 18:38:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C19E43851C1C Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 162IYK7C166983 for ; Fri, 2 Jul 2021 14:38:45 -0400 Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0b-001b2d01.pphosted.com with ESMTP id 39j5vxkeng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 02 Jul 2021 14:38:45 -0400 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 162IXZoa002617 for ; Fri, 2 Jul 2021 18:38:44 GMT Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by ppma03wdc.us.ibm.com with ESMTP id 39duveuf4a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 02 Jul 2021 18:38:44 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 162IcgIT25297226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jul 2021 18:38:42 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 939C2B2064; Fri, 2 Jul 2021 18:38:42 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F3B5BB2067; Fri, 2 Jul 2021 18:38:41 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.87.204]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 2 Jul 2021 18:38:41 +0000 (GMT) Message-ID: <2915ed3bce4756d4b6291ae3bf84a8b4a9ce67a7.camel@us.ibm.com> Subject: GDB reverse execution question From: Carl Love To: gdb@sourceware.org Cc: Rogerio Alves , Will Schmidt , Ulrich Weigand , cel@us.ibm.com Date: Fri, 02 Jul 2021 11:38:41 -0700 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-14.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: tRgvhmz4UrlDrvaWtJzNtcEv2jEYghIJ X-Proofpoint-GUID: tRgvhmz4UrlDrvaWtJzNtcEv2jEYghIJ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-02_09:2021-07-02, 2021-07-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 clxscore=1011 suspectscore=0 priorityscore=1501 phishscore=0 mlxscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107020097 X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 18:38:47 -0000 GCC maintainers: I am looking into some GDB regression test failures for reverse mode. The specific test I am currently looking at is gdb/testsuite/gdb.reverse/step-reverse.exp. I am running the test on a Power 9 machine with the test compiled with two different versions of the gcc compiler. The test runs fine using the distro compiler /usr/bin/gcc which is gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04). The issue occurs with a more recent build I have gcc version 10.3.1. where the test fails. Both of the compilers generate the same instruction sequences but the addresses of the assembly instructions differ slightly. Note, the tests are done with the default optimization for gcc. Inintially the test executes "forward", with record enabled, thru a couple of functions to the line in main with the label "FINISH TEST". The C code statement consists of five assembly instructions as shown below where I have put in generic addresses 1 to 7 as the actuall addresses differ slightly for the output of the two compilers: /* Test that "step" doesn't */ callee(); /* STEP INTO THIS CALL */ 1: 9bc: c9 fe ff 4b bl 884 /* Test "stepi" */ a[5] = a[3] - a[4]; /* FINISH TEST */ forward execution stops at this C code line 2: ce 01 5f e9 lwa r10,460(r31) pc is here, step reverse (distro compiler) 3: d2 01 3f e9 lwa r9,464(r31) 4: 50 50 29 7d subf r9,r9,r10 New gcc compiler, reverse step from FINISH TEST only gets to here not the previous source code line 5: b4 07 29 7d extsw r9,r9 6: d4 01 3f 91 stw r9,468(r31) pc is here for the "newer gcc compiler" callee(); /* STEPI TEST */ 7: b1 fe ff 4b bl 884 So as noted above, the distro test stops with PC at address 2 whereas the newer gcc stops at address 6. Power used to issue groups of up to 4 instructions at a time. Not sure that Power 9 still does that. I am still looking for the details on the instruction issuing on Power 9. But if it does still issue in groups, that could explain the difference in the PC given the different instruction addresses. I only mention all this as it is something of note but I don't think is the real problem. The issue occurs when the test switches to reverse and then does a step, in the reverse direction. In the case of the distro compiler which is at address 2, the step, in the reverse direction, stops in the previous line of C code. However, with the newer gcc the reverse step from address 6 only gets to address 4 which is still in the "FINISH TEST" C code line. The gdb test fails because the step is not at the "STEP INTO THIS CALL" C code line as is expected. I have been reading the gdb code in gdb/reverse.c and gdb/record-full.c etc. Recording stores the register and memory changes for each executed instruction. What I can't find is anything that records the association of instructions to C code lines. So when gdb does a reverse "step" how does it know how many assembly instructions to undo? I believe gdb uses the debug info to figure out where the next instruction. Don't know where/how this is done in the forward direction. Again, where/how would gdb make the determination in the reverse direction to decide where to stop? I have not been able to determine that in the code for doing reverse execution that I have been studying. The test fails because gdb doesn't unroll enough instructions to get to the previous source line when the PC is at address 6. I am wondering if someone can help me understand how gdb determins where/how to stop when doing a reverse step? Thanks for the help. Carl Love