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

[Joel Brobecker <brobecker@adacore.com>]

Hello,

On Wed, Feb 23, 2022 at 03:18:55PM -0800, Carl Love via Gdb-patches wrote:
> GCC maintainers:
> 
> The following patch fixes two Powerpc testsuite errors in
> gdb.base/ending-run.exp.  As stated below, the last two tests fail.  It
> seems the standard output on Powerpc is different then other platforms
> as described below.
> 
> Please let me know if the following patch is acceptable for gdb
> mainline.   Thanks.

Sorry for the delay in reviewing this.

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

Do you know what code we're inside of, by any chance?
In particular, can you confirm that it is normal that we don't
even have a minimal symbol for this code?

> (gdb) n
> Cannot find bounds of current function

Yeah, expected behavior based on the above.

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

So, if I recap, the testcase ending-run.exp is there to verify that
we can "next" our program's "main" all the way to the program's
exit.

The problem is that, on your platform, this is clearly not something
that we can do. We can see that it's having no problem "next"-ing
up until the program exits "main", but after that, it lands in
a section of code where GDB can't seem to determine what function
it belongs to. As a result of that, trying to do a "next" is not
possible.

If this recap is correct, and we are able to confirm that
the code calling "main" does indeed not have a minimal symbol
associated to it, then I think a high-level view of what
the testcase should do in this case is do "next" operations
until landing inside the unknown function in your libc function.
And from there, determine that there is no point in continuing
further.

If I understand the architecture of this testcase correctly...

> ---
>  gdb/testsuite/gdb.base/ending-run.exp | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..d00a002928e 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,11 @@ 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 $" {
> +	# Powerpc output for step out of main
> +	pass "step out of main"
> +	set program_exited_normally 1

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

Also, I think it is important in this case that we verify that
no only are we inside a powerpc library, but also that we landed
inside some code for which there is no entrin the symbol table.
For there, we should expand the comment to clearly explain under
which circumstances this has been seen, and what that means
for the rest of the testcase, thus explaining why we mark this
as a pass, *and* we set program_exited to 1.

... meanwhile, setting program_exited should also lead to
the next block of the testcase to skip the next wave of "next"
commands. And a result, program_exited_normally doesn't get
set, and we end up reporting an "unsuported" via...

    if {$program_exited_normally} {
        gdb_test "n" ".*The program is not being run.*" "don't step after run"
    } elseif {$program_not_exited} {
        unresolved "don't step after run"
    } else {
        unsupported "don't step after run"
    }

>  # When we're talking to a program running on a real stand-alone board,
> @@ -238,13 +243,18 @@ if {!$use_gdb_stub
>  		pass "step to end of run" 
>  		set program_in_exit 1
>  	    }
> +	    -re ".*Cannot find bounds of current function.*$gdb_prompt $" {
> +		# Powerpc output for step to end of run
> +		pass "step to end of run"
> +		set program_in_exit 1
> +	    }

... which, to me, means that this shouldn't be need.

What do you think?

-- 
Joel