Re: [PATCH] PowerPC: fix for gdb.base/eh_return.exp

[Kevin Buettner <kevinb@redhat.com>]

Hi Carl,

On Thu, 05 May 2022 13:07:29 -0700
Carl Love via Gdb-patches <gdb-patches@sourceware.org> wrote:

> PowerPC: fix for gdb.base/eh_return.exp
> 
> The expect file does a disassembly of function eh2 to get the address of
> the last instruction of function eh2.  The last instruction on PowerPC is
> followed by three .long entries.  This requires a different pattern
> matching for PowerPC versus other architectures.
> 
> This patch adds the needed gdb_test_multiple match statement for the
> PowerPC disassembly code.
> 
> This patch fixes the one test failure on PowerPC.
> 
> The patch has been tested on Power 10 and Intel 64.
> ---
>  gdb/testsuite/gdb.base/eh_return.exp | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
> index df55dbc72da..ce46a3623d9 100644
> --- a/gdb/testsuite/gdb.base/eh_return.exp
> +++ b/gdb/testsuite/gdb.base/eh_return.exp
> @@ -27,6 +27,22 @@ set address -1
>  
>  # Get the address of the last insn in function eh2.
>  gdb_test_multiple "disassemble eh2" "" {
> +    -re "($hex)\[^\r\n\]*blr.*" {
> +	# The dissassebmly on Powerpc looks like:
> +	#   Dump of assembler code for function eh2:
> +	#   0x00000000100009e0 <+0>:     lis     r2,4098
> +	#   ...
> +	#   0x0000000010000b04 <+292>:   add     r1,r1,r10
> +	#   0x0000000010000b08 <+296>:   blr
> +	#   0x0000000010000b0c <+300>:   .long 0x0
> +	#   0x0000000010000b10 <+304>:   .long 0x1000000
> +	#   0x0000000010000b14 <+308>:   .long 0x1000180
> +	#   End of assembler dump.
> +	#
> +	#  Powerpc needs the address for the blr instruction above.
> +	set address $expect_out(1,string)
> +	pass $gdb_test_name
> +    }
>      -re -wrap "($hex)\[^\r\n\]*\r\nEnd of assembler dump." {
>  	set address $expect_out(1,string)
>  	pass $gdb_test_name
> -- 

I'd prefer to see a solution which doesn't explicitly test for PPC's blr
or any other architecture specific instruction.

It seems to me that the problem results from the .long entries
following the last executable instruction.  My guess is that these
would be problematic on other architectures too.  I think it'd
be better to write an RE which skips all trailing occurrences of
$hex\[^\r\n\]*\.long\[^\r\n\]* .

Kevin