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

[Pedro Alves]

On 2022-05-06 19:08, Kevin Buettner via Gdb-patches wrote:
> 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\]* .

Do you know why those .long are there in the first place?  Kind of looks like
data in the middle of text?  I wonder whether that's a GDB bug or normal...