From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 975F33858D28 for ; Tue, 15 Mar 2022 02:48:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 975F33858D28 Received: by mail-wr1-x433.google.com with SMTP id q14so26898798wrc.4 for ; Mon, 14 Mar 2022 19:48:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3RdMFjp4eh2fdLSr/6oWXNRyFM7ghzVGYB5oJeFNaWE=; b=qWW91dGXhNB4e1EANTa9r1qxJIoAY9DmC5QwxJW/V8b/ar4SZRMC/z5JEMB791xUEl zjmkxWSQNld9Yuwpr6mAUJfadh26yF9hcXXvIjbi5z4MHB4cEtTIMwsB3dU/fvR2Ow9x Z3cU3kgpUXXYGfgkT587awOmYX27Mvbzye8GF4Azyk48CqE2m+rDjKWLXQpU7LIPhulf sQX0IqTWBr5Qvruv8Frj5GeqVkwnh3lP91WceQ1n5ka28YShqJyCqU+rmxefepY+vdPs jYBam8doX0lwstJ7fZpqcbFlJdDLPYiuhP1iGjbuSl5IYI5dPW07YOjuNZLoDKdfj3mR El2w== X-Gm-Message-State: AOAM532PRiwEUci9aKJFWbVrZOmPA9L9DTDi9b0i4mCsU5BM5W2ufyLi zWM3BFXsOgk5pO+FwQq54+Zq X-Google-Smtp-Source: ABdhPJxNVtnJYfX5taELvU1BaQF4WCaQaZOq0dQN4Usym32WEAhrKpq1FopuiX+kVk0Z/GEDQLlEVg== X-Received: by 2002:a5d:6c6b:0:b0:1ea:77ea:dde8 with SMTP id r11-20020a5d6c6b000000b001ea77eadde8mr18927938wrz.690.1647312486365; Mon, 14 Mar 2022 19:48:06 -0700 (PDT) Received: from takamaka.home ([2a01:cb22:1d5:1100:ec9b:fe41:fba6:974f]) by smtp.gmail.com with ESMTPSA id r17-20020a05600c35d100b00389f368cf1esm971670wmq.40.2022.03.14.19.48.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 19:48:05 -0700 (PDT) Received: by takamaka.home (Postfix, from userid 1000) id 305B7A4AD4; Tue, 15 Mar 2022 06:48:03 +0400 (+04) Date: Tue, 15 Mar 2022 06:48:03 +0400 From: Joel Brobecker To: Carl Love Cc: will schmidt , Joel Brobecker , Rogerio Alves , gdb-patches@sourceware.org Subject: Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f5513496ebbf7e0314c62183b1c5e198b3dda29.camel@us.ibm.com> X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, 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: Tue, 15 Mar 2022 02:48:09 -0000 Hi Carl, [off list] > > 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. > > Yes, the description was written before the key issue of the dbug-info > files was understood. That information was added after the fact but > you have to read fairly far into this rather long commit message to > find that. I agree, it should be brought to the top as it is the key > issue here. I re-worked the commite message per your comments. > > The patch with the updated commit message is below. > > 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..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 $" { Did you see the following comment I made? | 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? I hope this is understandable. I'm a little worried, because this is my third time asking this. Said differently, I think the regexp above should be enhanced to verify that landed at an address for which there is no symbolic information at all (i.e. "in ?? ()"). > + # 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 > > -- Joel