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

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

[Carl Love]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=879f2aae39e07aac6df72d8c6e25e2b6183fb0e6

commit 879f2aae39e07aac6df72d8c6e25e2b6183fb0e6
Author: Carl Love <cel@us.ibm.com>
Date:   Wed Mar 16 15:23:12 2022 +0000

    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.

Diff:
---
 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..906f1ac40ca 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 "0x.*\\?\\? \\(\\) 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"
+	set program_exited 1
+    }
 }
 
 # When we're talking to a program running on a real stand-alone board,