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 A394A3858D28 for ; Mon, 14 Mar 2022 17:52:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A394A3858D28 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22EHpfpC008240; Mon, 14 Mar 2022 17:51:59 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0a-001b2d01.pphosted.com with ESMTP id 3et6ahxkgq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Mar 2022 17:51:59 +0000 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 22EHo4KJ004548; Mon, 14 Mar 2022 17:51:58 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma03wdc.us.ibm.com with ESMTP id 3erk58qng2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Mar 2022 17:51:58 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22EHpvYJ49217956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 14 Mar 2022 17:51:57 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 11CB3124053; Mon, 14 Mar 2022 17:51:57 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5626412405B; Mon, 14 Mar 2022 17:51:56 +0000 (GMT) Received: from lexx (unknown [9.160.104.238]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 14 Mar 2022 17:51:56 +0000 (GMT) Message-ID: <2c97833cbbea1ad3004b49a962280cf0df41e788.camel@vnet.ibm.com> Subject: Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp From: will schmidt To: Carl Love , Joel Brobecker Cc: Rogerio Alves , gdb-patches@sourceware.org Date: Mon, 14 Mar 2022 12:51:55 -0500 In-Reply-To: <8933441b11ce054839d583eac3cb0d4e29d706af.camel@us.ibm.com> References: <479011be1a832692f38293ebf6f9cc0fd18315fa.camel@us.ibm.com> <32922e07bdf72b25c40b5ab3559a7b75f6e91e0c.camel@us.ibm.com> <8933441b11ce054839d583eac3cb0d4e29d706af.camel@us.ibm.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: OPpQ0IGyLmgo0QTM3WpdMVTSmFlagAed X-Proofpoint-ORIG-GUID: OPpQ0IGyLmgo0QTM3WpdMVTSmFlagAed X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-14_12,2022-03-14_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 suspectscore=0 priorityscore=1501 clxscore=1011 mlxlogscore=999 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203140106 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, 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: Mon, 14 Mar 2022 17:52:04 -0000 On Mon, 2022-03-14 at 08:54 -0700, Carl Love via Gdb-patches wrote: > Joel: > > My comment was rather minimalistic. Your comment is a much better > more > verbose statement. It looks good to me. Thanks. > > I updated the patch, attached below. > > Carl > > On Sun, 2022-03-13 at 09:21 +0400, Joel Brobecker wrote: > > Hi Carl, > > > > > diff --git a/gdb/testsuite/gdb.base/ending-run.exp > > > b/gdb/testsuite/gdb.base/ending-run.exp > > > index 32435b2b509..38a52b91e9c 100644 > > > --- a/gdb/testsuite/gdb.base/ending-run.exp > > > +++ b/gdb/testsuite/gdb.base/ending-run.exp > > > @@ -202,6 +202,13 @@ gdb_test_multiple "next" "step out of main" > > > { > > > # This is what happens on system using uClibc. > > > pass "step out of main" > > > } > > > + -re ".*from /lib/powerpc.*$gdb_prompt $" { > > > > I really think we should try to match the fact that we were unable > > to determine the name of the function in the frame information. > > Wouldn't otherwise the regexp above also match when your system > > does have the debugging information, incorrectly leading us to > > stop the testing when we should be able to continue? > > > > > + # This case occurs on Powerpc when gdb steps out of main and > > > the > > > + # needed debug info files are not loaded on the system so gdb > > > can > > > + # see it stepped to function into __libc_start_call_main. > > > > "stepped to function into xxx" seems odd. > > > > I'd like to also add an explanation as to why we set > > program_exited, > > and in particular why the situation we just detected makes us > > unable > > to continue the testing. > > > > What about... > > > > # This case occurs on Powerpc when gdb steps out of main and > > the > > # needed debug info files are not loaded on the system, > > preventing > > # GDB to determine which function it reached > > (__libc_start_call_main). > > # Ideally, the target system would have the necessary > > debugging > > # information, but in its absence, GDB's behavior is as > > expected. > > # > > # Another consequence of this missing information is that > > GDB > > # can no longer continue to perform "next" operations, as > > doing > > # so requires GDB to know the bounds of the current > > function. > > # Not know what the current function it, it cannot > > determine > > # its bounds. So we also set program_exited to 1 to > > indicate > > # that we need to stop this testcase at this stage of the > > testing. > > > --------------------------------------------------- > > Powerpc fix for gdb.base/ending-run.exp > > The last two tests in this test case fail. The next to the > last test does a next command when the program is stopped at > the closing bracket for main. On Powerpc, the message printed > is: Now that the situation is understood, i'd suggest updating the lead-in description to clarify that these tests fail when debuginfo is not found by GDB. That could be clarified further to indicate (... for glibc) or somesuch. The story could also be inverted a bit to clarify the situation. When debuginfo can not be found for glibc, this test will fail once the test program passes exit(), since it's stack/location in glibc space can not be determined. > > 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6 > > which fails to match any of the test_multiple options. > > The test then does another next command. On Powerpc, the > message printed it: > > Cannot find bounds of current function > > which again is not any of the options in the test_multiple. > > I checked the behavior on Powerpc to see if this is typical. > I ran gdb on the following simple program as shown below. > > #include > int > main(void) > { > printf("Hello, world!\n"); > return 0; > } > > gdb ./hello_world > > > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./hello_world... > (No debugging symbols found in ./hello_world) > (gdb) break main > Breakpoint 1 at 0x818 > (gdb) r > > Starting program: /home/carll/hello_world > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/powerpc64le-linux- > gnu/libthread_db.so.1". > > Breakpoint 1, 0x0000000100000818 in main () > (gdb) n > Single stepping until exit from function main, > which has no line number information. > Hello, world! > 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6 > (gdb) n > Cannot find bounds of current function > > So it would seem that the messages seen from the test case are > "normal" output for Powerpc. > > The following patch adds the output from Powerpc as an option > to the test_multiple, identifying them as the expected output > on Powerpc. > > The patch has been tested on a Power 10 system and an Intel > 64-bit system. No additional regression failures were seen on > either platform. > --- > gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/gdb/testsuite/gdb.base/ending-run.exp > b/gdb/testsuite/gdb.base/ending-run.exp > index 32435b2b509..7e2134556de 100644 > --- a/gdb/testsuite/gdb.base/ending-run.exp > +++ b/gdb/testsuite/gdb.base/ending-run.exp > @@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" { > # This is what happens on system using uClibc. > pass "step out of main" > } > + -re ".*from /lib/powerpc.*$gdb_prompt $" { > + # This case occurs on Powerpc when gdb steps out of main and > the > + # needed debug info files are not loaded on the system, > preventing > + # GDB to determine which function it reached > (__libc_start_call_main). > + # Ideally, the target system would have the necessary debugging > + # information, but in its absence, GDB's behavior is as > expected. > + # > + # Another consequence of this missing information is that GDB > + # can no longer continue to perform "next" operations, as doing > + # so requires GDB to know the bounds of the current function. > + # Not know what the current function it, it cannot determine > + # its bounds. So we also set program_exited to 1 to indicate > + # that we need to stop this testcase at this stage of the > testing. > + pass "step out of main" Should this pass statement add a hint about missing debuginfo? i.e. pass "step out of main, (missing libc debuginfo)" > + set program_exited 1 > + } > } > > # When we're talking to a program running on a real stand-alone > board,