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 7EE5D3857406 for ; Tue, 15 Mar 2022 15:51:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7EE5D3857406 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 22FETjsT021999; Tue, 15 Mar 2022 15:51:11 GMT Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 3etru2qadr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Mar 2022 15:51:11 +0000 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 22FFXCA3001384; Tue, 15 Mar 2022 15:51:10 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma05wdc.us.ibm.com with ESMTP id 3erk59xav4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Mar 2022 15:51:10 +0000 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 22FFp8SN12648924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 15 Mar 2022 15:51:09 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E310CB206C; Tue, 15 Mar 2022 15:51:08 +0000 (GMT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 97985B2065; Tue, 15 Mar 2022 15:51:07 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.79.233]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 15 Mar 2022 15:51:07 +0000 (GMT) Message-ID: <3410ee2b27ec5ccc0ceaecf6275bf79c69ca7895.camel@us.ibm.com> Subject: Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp From: Carl Love To: will schmidt , Joel Brobecker Cc: Rogerio Alves , gdb-patches@sourceware.org Date: Tue, 15 Mar 2022 08:51:06 -0700 In-Reply-To: <5f5513496ebbf7e0314c62183b1c5e198b3dda29.camel@us.ibm.com> References: <479011be1a832692f38293ebf6f9cc0fd18315fa.camel@us.ibm.com> <32922e07bdf72b25c40b5ab3559a7b75f6e91e0c.camel@us.ibm.com> <8933441b11ce054839d583eac3cb0d4e29d706af.camel@us.ibm.com> <2c97833cbbea1ad3004b49a962280cf0df41e788.camel@vnet.ibm.com> <5f5513496ebbf7e0314c62183b1c5e198b3dda29.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-ORIG-GUID: Mnl2BsbwFc9bte9vF26-Vur17E89zx9l X-Proofpoint-GUID: Mnl2BsbwFc9bte9vF26-Vur17E89zx9l 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-15_03,2022-03-15_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 bulkscore=0 suspectscore=0 phishscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203150101 X-Spam-Status: No, score=-12.1 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_NONE, 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: Tue, 15 Mar 2022 15:51:15 -0000 Joel, GDB maintainers: Per the convesation I had with Joel, there is an issue with the regexp. The regexp for the missing debug info case on Power needs to include the "?? ()" in the regular expression to match the case where gdb can't find the name and prints ?? rather then the actual name. Otherwise, the new gdb_test_multiple could match the case where a function name was printed. I tested the updated patch on a Power 10 system that does not have the debug info installed and on a system that does have the debug info to verify the new test entry is only hit when the debug info is missing. Hopefully, this addresses all of the issues with the patch. Carl Love ------------------------------------------ Powerpc fix for gdb.base/ending-run.exp The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the system does not have the needed glibc debug-info files loaded. In this case, gdb is not able to determine where execution stopped. This behavior looks as follows for the test case: The next to the last test does a next command when the program is stopped at the closing bracket for main. The message printed is: 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 The test fails as the output does not match any of the options for the gdb_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 when the debug-info is not available. The following patch adds the output from Powerpc as an option to the gdb_test_multiple statement, identifying the output as the expected output on Powerpc without the needed debug-info files installed. 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..906f1ac40ca 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 "0x.*\\?\\? \\(\\) 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" + set program_exited 1 + } } # When we're talking to a program running on a real stand-alone board, -- 2.32.0