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 5552F3858CDA for ; Mon, 26 Sep 2022 15:30:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5552F3858CDA Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28QE1fGB016111; Mon, 26 Sep 2022 15:30:56 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3judg0k6yh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Sep 2022 15:30:56 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 28QFKP0S015057; Mon, 26 Sep 2022 15:30:55 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma04dal.us.ibm.com with ESMTP id 3jsshajfbb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Sep 2022 15:30:55 +0000 Received: from smtpav05.wdc07v.mail.ibm.com ([9.208.128.117]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28QFUsop4850214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Sep 2022 15:30:54 GMT Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1F2FC58061; Mon, 26 Sep 2022 15:30:54 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1D9CD58043; Mon, 26 Sep 2022 15:30:53 +0000 (GMT) Received: from sig-9-65-248-8.ibm.com (unknown [9.65.248.8]) by smtpav05.wdc07v.mail.ibm.com (Postfix) with ESMTP; Mon, 26 Sep 2022 15:30:52 +0000 (GMT) Message-ID: <4bb7ce2d41f5623a8866a9e631e3cda48a6a0e04.camel@us.ibm.com> Subject: Re: 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: Ulrich Weigand , "gdb-patches@sourceware.org" , "luis.machado@arm.com" Date: Mon, 26 Sep 2022 08:30:52 -0700 In-Reply-To: References: <1398bb10-2ed9-c074-0627-43d7e2feddea@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: WuKH0VGKMXkuTLIz94rlyPG-WQQIjgf0 X-Proofpoint-GUID: WuKH0VGKMXkuTLIz94rlyPG-WQQIjgf0 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-26_08,2022-09-22_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 spamscore=0 clxscore=1011 malwarescore=0 mlxlogscore=999 priorityscore=1501 adultscore=0 lowpriorityscore=0 phishscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209260096 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: Mon, 26 Sep 2022 15:31:00 -0000 Ulrich, Luis: On Mon, 2022-09-26 at 14:36 +0000, Ulrich Weigand wrote: > Luis Machado wrote: > > > gdbarch has a hook to adjust the breakpoint address > > (gdbarch_adjust_breakpoint_address). Can this be used to bend > > commands > > like "b *func" so they behave the same as other architectures? > > I don't think this works. The problem is that "b *func" is a weird > hack that combines two aspects: use of "func" as a value that at this > point is just a plain symbol table lookup; and use of "*" to set a > breakpoint at an explicitly specified absolute address. > > Neither of these aspects is something we want to change on its own. > We do want a plain symbol, if used as a value, to return the > address that is in the symbol table. Everything else would just > be confusing, and could also break things if "if ptr == func" > where "ptr" is a function pointer variable. > > On the other hand, when using "b *" with some hard-coded > address, we actually want the breakpoint to be exactly there > and nowhere else; that is usually used by someone familiar with > the platform who want to set the breakpoint exactly there. (Or, > possibly, by clicking on "set breakpoint" in a GUI switched to > the assembly view.) Automatically moving this to a different > address would be weird, when the whole point of "*" is that it > *isn't* trying to be clever, unlike say "b func". > > It is an unfortunate fact that these two properties, which are > each desired on their own, combine to yield an undesirable > effect when used as "b *func" on Power. But I think the root > cause of this is that "b *func" is used here in a way that is > not justified by the actual specification of those features. > > Actually, I'm not seeing much use of this particular construct > at all, outside of the GDB test suite. And here, it is used > in the idiosyncratic manner of "do a 'b func' but just without > skipping the prolog", usually because of some GDB test suite > internal reason why we want to avoid prolog skipping just here. > > It seems to me that the real fix would be some new syntax that > makes this goal explicit, maybe along the lines of > b -entrypoint func > > (It would still be preferable to me to investigate use of this > construct throughout the test suite to see if it is *really* > necessary or if the tests can simply be rewritten in a way > that they don't need the "skip prolog" feature anyway ...) I looked at the suggestion from Luis. In the end, I really didn't think changing gdb to make the test work is really the best idea. The issue is that there are cases, as Ulrich said, where someone who knows the details may actually want to set the breakpoint on the first instruction. If I change gdb, to fix the test by "adjusting" the desired breakpoint then the user is no longer able to stop where they want to. I am not sure why the original test was concerned about the prolog. The original author doesn't seem to be around anymore. I will think about how to change the first test some more. I don't see any issues with changing the second test to just break on the function callee rather than *callee. I will submit a patch to change the second test. Carl