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 E2FFE3858D38 for ; Thu, 22 Sep 2022 18:24:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E2FFE3858D38 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28MHnwlM036670; Thu, 22 Sep 2022 18:24:02 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jrvf0gt5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Sep 2022 18:24:02 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28MI9xrP019796; Thu, 22 Sep 2022 18:24:01 GMT Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jrvf0gt4k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Sep 2022 18:24:01 +0000 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 28MIKQ79026149; Thu, 22 Sep 2022 18:24:01 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma01dal.us.ibm.com with ESMTP id 3jn5vab3bf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Sep 2022 18:24:00 +0000 Received: from smtpav03.dal12v.mail.ibm.com ([9.208.128.129]) by b03cxnp07027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28MINxkI58655108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Sep 2022 18:23:59 GMT Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7B02E58060; Thu, 22 Sep 2022 18:23:59 +0000 (GMT) Received: from smtpav03.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8ECBD5803F; Thu, 22 Sep 2022 18:23:58 +0000 (GMT) Received: from sig-9-65-248-8.ibm.com (unknown [9.65.248.8]) by smtpav03.dal12v.mail.ibm.com (Postfix) with ESMTP; Thu, 22 Sep 2022 18:23:58 +0000 (GMT) Message-ID: Subject: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp From: Carl Love To: "gdb-patches@sourceware.org" Cc: Will Schmidt , cel@us.ibm.com, Ulrich Weigand , Pedro Alves , Pedro Alves Date: Thu, 22 Sep 2022 11:23:57 -0700 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: V5juaafGypTRBllBfgOcfb4sypCpOFfc X-Proofpoint-GUID: c96OsYb9HlA5jD3AjNK-MbgD3o2HhlV5 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-22_12,2022-09-22_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 suspectscore=0 clxscore=1011 impostorscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=711 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209220119 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, 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 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: Thu, 22 Sep 2022 18:24:06 -0000 GDB community: There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar reasons on PowerPC. It appears to me that the issues are with the tests and not with gdb itself. Both tests set breakpoints on *func where func is a function in the source file. This is the fundamental issue with both tests. The test gdb.reverse/finish-reverse-bkpt.exp has the comment: gdb_test "tbreak void_func" \ "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ "set breakpoint on void_func" gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" # We stop at the brekapoint on void_func, but breakpoint on # *void_func will be set at the same place if function void_func doesn't # have prologue. One step forward to avoid this. gdb_test "si" gdb_test "break \*void_func" \ "Breakpoint $decimal at .*" \ "set breakpoint at void_func's entry" The comment about break point on void_func and breakpoint on *void_func being the same if there is no prolong is not true for all architectures. Specifically PowerPC uses local and global entry points. The statement "break *foo" sets the breakpoint at the address of the first instruction in the function where as "break foo" sets the breakpoint at the beginning of the function, i.e. after the prolog following the local entry point. Specifically for this test the PowerPC assembly code is as follows: void void_func () { 1000068c: 02 10 40 3c lis r2,4098 <-global entry point, location of break *void_func 10000690: 00 7f 42 38 addi r2,r2,32512 10000694: f8 ff e1 fb std r31,-8(r1) <-local entry point 10000698: d1 ff 21 f8 stdu r1,-48(r1) <-prolog 1000069c: 78 0b 3f 7c mr r31,r1 <-prolog void_test = 1; /* VOID FUNC */ 100006a0: 00 00 00 60 nop <- location of break void_func 100006a4: 58 81 22 39 addi r9,r2,-32424 100006a8: 01 00 40 39 li r10,1 .... The test fails on PowerPC because the reverse execution never hits the breakpoint at *void_func because the function is called using the local entry point. Thus gdb returns to the caller after it reaches the local entry point at address 10000694. It does not continue executing back to the global entry point. The global entry point is only used in special cases when the Table of Contents (TOC) pointer is not already setup in r2. The question is how to fix the test in general? 1) Changing the breakpoint on *void_func to void_func will cause both breakpoints to be the same regardless if there is a prolog. That change would seem to invalidate the point of the test? 2) Disable the test for architectures where the assumption breakpoint on foo and breakpoint on *foo is the same except for a prolog. The downside is we are missing testing of some gdb functionality. Is there another way to fix this test to run correctly on PowerPC? The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because it does a break on *callee. Specifically, set lineno [gdb_get_line_number "STEP INTO THIS CALL"] gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" gdb_test "b \*callee" "" "set breakpoint at callee's entry" set bpnum [get_integer_valueof "\$bpnum" 0] gdb_test "reverse-next" \ "Breakpoint $bpnum, callee.*" \ "reverse-next over call trips user breakpoint at function entry" gdb_test "up" \ ".*NEXT OVER THIS CALL.*" \ "stopped at the right callee call" In this case, it looks to me like changing the gdb_test to callee instead of *callee doesn't break the point of the test. Making the change on PowerPC fixes the test. Does anyone see any issues with changing the breakpoint from *callee to calle for this test? Thanks for the input and help fixing these tests on PowerPC. Carl Love