From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 3E1443858C39 for ; Fri, 13 Jan 2023 19:10:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3E1443858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=us.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=us.ibm.com Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30DHtkcw015557 for ; Fri, 13 Jan 2023 19:10:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version : subject; s=pp1; bh=p4LqvZrdSNWIF5Avel2O9Jl13G/7Tg7a7xpFGoMLims=; b=bXF52KfuuJ3VQ0Fn9bV4fcXshA+4/kZkqsm6t0C40idPRlbHSj6zZcI+m+9AWCgV6t9R oCORY2FkorBiFgYDhe6tHt70Letkn1Pyj9a92g7CG4RSD5j8hj3UobpcbC5EpTwai8gz kLIyF6mAKdTWoY0wehFSXUr5w21zXlsGDXMvvrPde2xHLgi62j1mdY8x4mq9ERhKePZT H6JR+NA26iE6/oRONWj8AH+xKeNRnlkcKfU3ThCW7DVij0mUjsnpt2iQVWn4sXLTVmz0 QLWTM/tbg8DKqbbjRpY/9vPLulW36GD8GPuaOcAieJ0Gy540+PVT9Q28D4iukpJfckQc 8w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n3c4phtmy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Jan 2023 19:10:54 +0000 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30DIpJ9P019506 for ; Fri, 13 Jan 2023 19:10:54 GMT Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3n3c4phtmn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Jan 2023 19:10:54 +0000 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30DGiuPi001744; Fri, 13 Jan 2023 19:10:53 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([9.208.129.114]) by ppma04wdc.us.ibm.com (PPS) with ESMTPS id 3n1kmascwf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Jan 2023 19:10:53 +0000 Received: from smtpav01.wdc07v.mail.ibm.com (smtpav01.wdc07v.mail.ibm.com [10.39.53.228]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30DJAqb241943524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jan 2023 19:10:52 GMT Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2BC1258059; Fri, 13 Jan 2023 19:10:52 +0000 (GMT) Received: from smtpav01.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8AB4D58055; Fri, 13 Jan 2023 19:10:51 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.163.12.142]) by smtpav01.wdc07v.mail.ibm.com (Postfix) with ESMTP; Fri, 13 Jan 2023 19:10:51 +0000 (GMT) Message-ID: <9293586a056601d7f515f2ed4176b469b092bb2f.camel@us.ibm.com> From: Carl Love To: Bruno Larsen , Ulrich Weigand , "will_schmidt@vnet.ibm.com" , gdb-patches@sourceware.org Cc: cel@us.ibm.com Date: Fri, 13 Jan 2023 11:10:51 -0800 In-Reply-To: <163c8487-f5c1-2b10-697e-6f695112b352@redhat.com> References: <51c4bfc82ac72e475e10577dc60e4d75fa48767e.camel@de.ibm.com> <3ea97a8aa9cccb39299adde682f92055d1986ab3.camel@us.ibm.com> <53878e37c6e57de1d04d9c9960c5d0a74324ee6e.camel@us.ibm.com> <50474aa92ba82eff05cdc8f49001eae56be29670.camel@us.ibm.com> <89331c26795e3f7743e1e068dce43b3c2dd53008.camel@us.ibm.com> <071f24ecf9b3a2bbbe8fee7db77492eb55c5f3ff.camel@us.ibm.com> <1d9b21914354bef6a290ac30673741e722e11757.camel@de.ibm.com> <3e3c9c40f07ab01c79fe10915e76ffa187c42ad9.camel@us.ibm.com> <41aed5ea42d8888d9bc40c5102088e89e389937c.camel@us.ibm.com> <163c8487-f5c1-2b10-697e-6f695112b352@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: z8sjW7WDCc7LISV6JmDX4gnN5DfKgoUh X-Proofpoint-GUID: ZMp_7aKpAMWi8Qd9EE5azpDt8RHJK3Q3 Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 Subject: RE: [PATCH 1/2] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-13_09,2023-01-13_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 mlxscore=0 bulkscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301130130 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,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 List-Id: Bruno: On Fri, 2023-01-13 at 18:04 +0100, Bruno Larsen wrote: > > I haven't run into the issue that mentioned about GDB not > > responding in > > the epilogue. I will have to go play with that to see if I can > > reproduce it. If you have any specific instructions on how you ran > > into it that would be interesting and helpful. > > I manually ran gdb.reverse/finish-precsave (setting recording, of > course), set a temporary breakpoint on void_func, nexted once to be > in > the epilogue and tried to reverse finish. I'm not sure if it was > some > stale file before I recompiled the test, though. > > Anyway, sorry if I was unclear, but that is not a regression of your > patch. Rather, you patch fixed that issue, I just want that test to > confirm that we don't accidentally regress it. You were clear that you saw this as an existing issue before applying my patches, i.e. not a regression due to my patch. But rather my patch fixed an existing issue. I have been playing around on my X86 box trying to reproduce the issue. I have an X86 box running Ubuntu 22.04.1 LTS, gcc version Ubuntu 11.3.0-1ubuntu1~22.04. Here is the log of what I did trying to reproduce the issue as you described: Note, I started by running make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.reverse/finish-precsave.exp' to generate the binary for the test. I then cd'd to ~/GDB/build-finish-precsave/gdb/testsuite/outputs/gdb.reverse/finish-precsave where the binary was saved. Then I ran the test. The following is the results with the path names to the files shortened to improve readability. gdb ./finish-precsave GNU gdb (GDB) 14.0.50.20230111-git Reading symbols from ./finish-precsave... (gdb) break main Breakpoint 1 at 0x11d3: file .../binutils-gdb-finish-precsave/gdb/testsuite/gdb.reverse/finish-reverse.c, line 95. (gdb) r Starting program: .../gdb/testsuite/outputs/gdb.reverse/finish-precsave/finish-precsave [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main (argc=1, argv=0x7fffffffe798) at .../binutils-gdb-finish-precsave/gdb/testsuite/gdb.reverse/finish-reverse.c:95 95 for (i = 0; i < sizeof (testval.ffff); i++) (gdb) record (gdb) tb void_func Temporary breakpoint 2 at 0x555555555131: file .../binutils-gdb-finishrecsave/gdb/testsuite/gdb.reverse/finish-reverse.c, line 44. (gdb) c Continuing. Temporary breakpoint 2, void_func () at .../binutils-gdb-finish-precsave/gdb/testsuite/gdb.reverse/finish-reverse.c:44 44 void_test = 1; /* VOID FUNC */ (gdb) next 45 } (gdb) reverse-finish Run back to call of #0 void_func () at .../binutils-gdb-finish-precsave/gdb/testsuite/gdb.reverse/finish-reverse.c:45 0x00005555555551fd in main (argc=1, argv=0x7fffffffe798) at ../binutils-gdb-finish-precsave/gdb/testsuite/gdb.reverse/finish-reverse.c:98 98 void_func (); /* call to void_func */ (gdb) reverse-step 98 void_func (); /* call to void_func */ (gdb) q I have tried stopping in the other functions as well. The reverse- finish still seems to work fine. I also tried setting layout-asm once I reached the function and then did si to reach various instructions in the epilog. Didn't seem to matter which instruction in the function I was at when I issued the reverse-finish instruction, I was not able to get gdb to hang. Unfortunately, I was not able to reproduce the issue on X86. I have also tried reproducing the error on PowerPC without success. I created a new test case to do the above tests. My thought is if we can get this new test case to reliably fail on your system without my proposed patches, then we can add it to the new test case in the patch. The test case passes on my X86 machine. Of course it fails on my PPC machine due to the existing reverse finish issues. What do you think? Carl ------------------------------------------- reverse-finish hang test --- .../gdb.reverse/gdb-reverse-finish-hang.exp | 54 +++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 gdb/testsuite/gdb.reverse/gdb-reverse-finish-hang.exp diff --git a/gdb/testsuite/gdb.reverse/gdb-reverse-finish-hang.exp b/gdb/testsuite/gdb.reverse/gdb-reverse-finish-hang.exp new file mode 100644 index 00000000000..14a3991c9b9 --- /dev/null +++ b/gdb/testsuite/gdb.reverse/gdb-reverse-finish-hang.exp @@ -0,0 +1,54 @@ +# Copyright 2008-2023 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# This file is part of the GDB testsuite. It tests 'finish' with +# reverse debugging. + +if ![supports_reverse] { + return +} + +standard_testfile finish-reverse.c +set precsave [standard_output_file finish.precsave] + +if { [prepare_for_testing "failed to prepare" "$testfile" $srcfile] } { + return -1 +} + +runto_main + +if [supports_process_record] { + # Activate process record/replay + gdb_test_no_output "record" "turn on process record" +} + +# Test reverse finish from void func to see if gdb hangs. +set breakloc [gdb_get_line_number "VOID FUNC" "$srcfile"] +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.*" + +# Step into epilogue of void_func. +gdb_test "step" ".*}.*" "step to epilog" + +# Test to see if gdb hangs when doing a reverse-finish from the epilogue. +gdb_test "reverse-finish" "$decimal.*void_func.*" \ + "return to caller of void_func ()" + +# Do reverse-next, should stay on void_func function due to existing bug +# in reverse-finish. +gdb_test "reverse-next" "$decimal.*void_func.*" \ + "reverse next in main" -- 2.34.1