Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[will schmidt <will_schmidt@vnet.ibm.com>]

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 <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.
> 
> 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,