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

[Joel Brobecker]

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