[PATCH] Powerpc fix for gdb.base/eh_return.exp

[PATCH] Powerpc fix for gdb.base/eh_return.exp

[Carl Love]

GDB maintainers:

The following patch fixes the one testfailure in gdb.base/eh_return.exp
on Powerpc.  Basically, the output format of the disassembly for
Powerpc is a little different requiring an additional test for Powerpc
in the gdb_test_multiple statement.

The patch has been tested on a Power 10 platform and on an Intel 64-bit 
system.  No test regressions were found.

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

                Carl Love


-----------------------------------------------
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 Intel and Power.

This patch adds the needed gdb_test_multiple match statement for the
Powerpc disassembly code.

This patch fixes the one test failure on Powerpc.
---
 gdb/testsuite/gdb.base/eh_return.exp | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
index df55dbc72da..041df5f2c84 100644
--- a/gdb/testsuite/gdb.base/eh_return.exp
+++ b/gdb/testsuite/gdb.base/eh_return.exp
@@ -26,7 +26,35 @@ if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
 set address -1
 
 # Get the address of the last insn in function eh2.
+# 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
+#
+# The dissassembly on Intel looks like:
+#   Dump of assembler code for function eh2:
+#   0x00000000004012cf <+0>:     endbr64
+#   0x00000000004012d3 <+4>:     push   %rbp
+#   ...
+#   0x000000000040134d <+126>:   pop    %rcx
+#   0x000000000040134e <+127>:   jmp    *%rcx
+#   End of assembler dump.
+#
+# Intel needs the address of the last jmp instruction
+
 gdb_test_multiple "disassemble eh2" "" {
+    -re "($hex)\[^\r\n\]*blr.*" {
+	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
-- 
2.32.0

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

[will schmidt]

On Fri, 2022-05-06 at 22:16 +0100, Pedro Alves wrote:
> 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...

That appears to be the Traceback Table, which is mentioned in the
PowerPC ABIs.   (64-bit PowerPC ELF Application Binary Interface
Supplement v1.9 section 3.3 ; and 64-Bit ELF V2 ABI specification v2
section 3.8.3).  "Compilers should generate a traceback table following
the end of the code for every function."

GCC has options to completely
disable or expand the content in the table, via the options "-
mtraceback={no,part,full}".
Thus, the amount of content after that last
blr could vary significantly.


 
Thanks,
-Will

Re: [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...

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

[Kevin Buettner]

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

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

[Carl Love]

GDB maintainers:

The following patch fixes a test failure on PowerPC.  The test needs to
determing the last instruction in function e2.  The current parsing to
get the last instruction doesn't work on PowerPC as there are three
additional .long statements after the last instruction.

This patch adds an entry to the gdb_test_multiple statement to parse
the PowerPC assembly code to get the address. 

The patch has been tested on PowerPC and Intel with no regression
failures.  Please let me know if this patch is acceptable.  Thanks.

                                  Carl Love
----------------------------------------------
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
-- 
2.31.1