public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, Rogerio Alves <rogealve@br.ibm.com>,
	cel@us.ibm.com
Subject: RE: [PATCH] Powerpc fix for gdb.base/ending-run.exp
Date: Fri, 11 Mar 2022 09:49:11 -0800	[thread overview]
Message-ID: <32922e07bdf72b25c40b5ab3559a7b75f6e91e0c.camel@us.ibm.com> (raw)
In-Reply-To: <Yiqz1TLsHiXetJSF@adacore.com>

Joel, GDB maintainers:

On Fri, 2022-03-11 at 06:28 +0400, Joel Brobecker wrote:
> 
> [...]
> > Anyway, it does appear that once you step off of the test program
> > you
> > end up in function __libc_start_call_main.  
> 
> Good to know. Perhaps you could mention that in a comment inside
> the block handling this scenario.

I added comments as requested to the gdb_test_multiple statement to
handle the case for Power when the needed debug info files are not
installed.
> 
> > > ... I would set program_exited instead of
> > > program_exited_normally.
> > > In fact, I think there was a confusion about this, since
> > > program_exited_normally gets unconditionally set just a few
> > > lines below.
> > 
> > I made the change you mentioned above and removed the additional
> > power gdb_test_multiple clause below.  The test also passes with
> > these
> > changes.
> 
> OK, good.
> 
> > The error occurs on Ubuntu on Power 10.  Per a suggestion, I tested
> > the
> > patch on a Red Hat distro.  The test passes fine there.  Ubuntu
> > puts
> > the debug info symbols in separate packages from the development
> > packages.  I have been thru the list of available packages and
> > tried
> > installing all the relavent packages to no avail.
> > 
> > The guess is with the proper symbols available on Ubuntu, the test
> > will
> > pass without my patch.  Just don't know what the missing package
> > is.
> 
> I don't think this is a problem. For me, the testcase should be
> able to be adapt to the distro it is running on, and if it is
> running on a distro that doesn't allow the testcase to run properly,
> then it should handle it gracefully (ideally).

I also updated the commit message to say the output is normal on
Powerpc when the debug info files are not installed.

The patch was tested on a refreshed copy of the latest mainline git
tree.  The two test failures were fixed with no additional regression
failures. 

Please let me know if the patch is acceptable with the above fixes.  
Thanks for your time and help with the patch.

                          Carl Love

------------------------------------------------
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:

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 <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

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.  Further investigation revealed that this
behavior is the result of the system not having all the needed debug info
files installed.  With the debug info files installed on the system the
test passes without this patch.

The following patch adds the output from Powerpc as an option
to the test_multiple, identifying the output as the expected output
on Powerpc when the debug info files are not 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 | 7 +++++++
 1 file changed, 7 insertions(+)

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 $" {
+	# 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.
+	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



  reply	other threads:[~2022-03-11 17:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 23:18 Carl Love
2022-02-28 18:02 ` [PING PATCH] " Carl Love
2022-03-06 11:12 ` [PATCH] " Joel Brobecker
2022-03-07 23:59   ` Carl Love
2022-03-08 18:41     ` Carl Love
2022-03-11  2:28     ` Joel Brobecker
2022-03-11 17:49       ` Carl Love [this message]
2022-03-13  5:21         ` Joel Brobecker
2022-03-14 15:54           ` Carl Love
2022-03-14 17:51             ` will schmidt
2022-03-14 21:32               ` Carl Love
2022-03-15  2:48                 ` Joel Brobecker
2022-03-15 15:51                 ` Carl Love
2022-03-16  3:30                   ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32922e07bdf72b25c40b5ab3559a7b75f6e91e0c.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=rogealve@br.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).