Fix gdb.ada/O2_float_param.exp for PowerPC

  GDB maintainers:

The gdb.ada/O2_float_param.exp for PowerPC test fails due to a
difference in the output of the frame command.  On PowerPC, the frame
command prints the address in addition to the rest of the information. 
The address is not printed on X86.  This patch updates the expect
string to account for the presence or absence of the address in the
output.

The patch fixes two failures in the test on PowerPC.  The patch has
been regression tested on Power 10 with no additional failures.

Please let me know if this patch is acceptable for mainline.  Thanks.

                     Carl 


----------------------------------
Fix gdb.ada/O2_float_param.exp for PowerPC

The frame command on Power pc prints the address in hex between the
#0 and in calle.increment.  For example

(gdb) frame
#0  0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
    at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
19	   procedure Increment (Val : in out Float; Msg: String) is

Update the set re string to accept the hex address.

Fixes two failures on PowerPC.

Patch tested on Power10 with no new regressions.
---
 gdb/testsuite/gdb.ada/O2_float_param.exp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
  

>>>>> "Carl" == Carl Love via Gdb-patches <gdb-patches@sourceware.org> writes:

Carl> Fix gdb.ada/O2_float_param.exp for PowerPC

Carl> The frame command on Power pc prints the address in hex between the
Carl> #0 and in calle.increment.  For example

Carl> (gdb) frame
Carl> #0  0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
Carl>     at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
Carl> 19	   procedure Increment (Val : in out Float; Msg: String) is

Carl> +    # Note, on PowerPC the output line looks like:
Carl> +    # #0  0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
Carl> +    # Not all architectures print the address.

I don't think this is architecture-dependent.  Instead, something else
is going wrong here.  Why exactly is it printing the address?  The code
here looks like:

    if (opts.addressprint)
      if (!sal.symtab
	  || frame_show_address (frame, sal)
	  || print_what == LOC_AND_ADDRESS)

Could it maybe be different inlining decisions?
Maybe seeing which of those clauses is true would show the answer.

I don't mind working around differences like this by patching the tests,
but I would like the real cause to be known and put into the comment.

Tom
  

On Fri, 2023-08-04 at 10:05 -0600, Tom Tromey wrote:
<snip>
> 
> Carl> +    # Note, on PowerPC the output line looks like:
> Carl> +    # #0  0x0000000010010a88 in callee.increment (
> val=val@entry=99.0, msg=...)
> Carl> +    # Not all architectures print the address.
> 
> I don't think this is architecture-dependent.  Instead, something
> else
> is going wrong here.  Why exactly is it printing the address?  The
> code
> here looks like:
> 
>     if (opts.addressprint)
>       if (!sal.symtab
> 	  || frame_show_address (frame, sal)
> 	  || print_what == LOC_AND_ADDRESS)
> 
> Could it maybe be different inlining decisions?
> Maybe seeing which of those clauses is true would show the answer.
> 
> I don't mind working around differences like this by patching the
> tests,
> but I would like the real cause to be known and put into the comment.

OK, I was able to get Ada installed on my X86 laptop so I could put in
debug prints on PowerPC and X86-64.  Thanks for the help identifying
where the print occurs.  

The function frame_show_address (frame, sal) returns true on PowerPC. 
The return statement for frame_show_address (frame, sal) is

   return get_frame_pc (frame) != sal.pc || !sal.is_stmt;

On PowerPC sal.is_stmt is false for this test but it is true on X86-64.

The result is the code you gave above, from print_frame in gdb/stack.c,
evaluates to true and the address is printed on PowerPC.

I updated the comment in the patch as:

+    # If sal.is_stmt is false for the frame, function frame_show_address will
+    # return true and function print_frame in gdb/stack.c will print the
+    # address.  In this case, the output will look something like:
+    # #0  0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
+    # This situation currently occurs on PowerPC but not on X86-64.
+    # The re string needs to account for the possibility that the address
+    # will be printed.
     set re \
-	"#0\\s+callee\\.increment \\(val(=val@entry)?=99\\.0, msg=\\.\\.\\.\\).*"
+	"#0.*callee\\.increment \\(val(=val@entry)?=99\\.0, msg=\\.\\.\\.\\).*"
     set re_different_entry_val \

to describe when the address is printed.  I noted that the address is
printed when sal.is_stmt is false as is currently the case on PowerPC. 

I will post version two of the patch for review.

Thanks for the help on this patch.

                                 Carl
  

Carl> The function frame_show_address (frame, sal) returns true on PowerPC. 
Carl> The return statement for frame_show_address (frame, sal) is

Carl>    return get_frame_pc (frame) != sal.pc || !sal.is_stmt;

Carl> On PowerPC sal.is_stmt is false for this test but it is true on X86-64.

That seems strange as well.

Tom