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

[Carl Love <cel@us.ibm.com>]

Joel, GDB maintainers:

Per the convesation I had with Joel, there is an issue with the regexp.
The regexp for the missing debug info case on Power needs to include
the "?? ()" in the regular expression to match the case where gdb can't
find the name and prints ?? rather then the actual name.  Otherwise,
the new gdb_test_multiple could match the case where a function name
was printed.

I tested the updated patch on a Power 10 system that does not have the
debug info installed and on a system that does have the debug info to
verify the new test entry is only hit when the debug info is missing.

Hopefully, this addresses all of the issues with the patch.

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