[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 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

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

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

[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

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

[Carl Love]

Will, Pedro, Kevin, GDB maintainers:

Sorry, resend, the first attempt was missing the mailing list.

I have updated the patch per the comments from Will.  The new version
of the patch uses a PowerPC specific gcc option to suppress the
generation of the Traceback Table information.  The Traceback
information is contained in the .long statements following the last
instruction in the function.  Now the existing test to locate the last
instruction in the function works without any changes.

Note, the use of the gcc mtraceback option is not valid on other
architectures.

I have tested the patch on Power 10 and Intel.

Please let me know if this patch is acceptable.  Thanks for the input
and help with the patch.

                          Carl Love
-----------------------------------------------------------------

PowerPC: fix for gdb.base/eh_return.exp

Disable the Traceback Table generation on PowerPC.  The Traceback Table
consists of multiple .long statement following the final instruction in
the function.  Generation of the .long statements needs to be disabled with
the PowerPC specific gcc compiler option -mtraceback=no so the test will
correctly locate the address of the bclr instruction before the statement
"End of assembler dump."
---
 gdb/testsuite/gdb.base/eh_return.exp | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
index df55dbc72da..3a49464af63 100644
--- a/gdb/testsuite/gdb.base/eh_return.exp
+++ b/gdb/testsuite/gdb.base/eh_return.exp
@@ -18,8 +18,30 @@
 
 standard_testfile
 
+if {[istarget "powerpc*"]} then {
+    # PowerPC generates a Traceback Table following each function by default.
+    # The .long statements following the function contain the Traceback Table
+    # information.  For example:
+    #   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.
+    #
+    # Disable the Traceback Table generation, using the PowerPC specific
+    # gcc option, so the test gdb_test_multiple "disassemble eh2" will match
+    # the blr instruction not the .long statement.
+    set compile_flags {debug nopie additional_flags=-mtraceback=no}
+} else {
+    set compile_flags {debug nopie}
+}
+
 if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
-	 {debug nopie}]} {
+	 $compile_flags]} {
     return -1
 }
 
-- 
2.31.1

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

[will schmidt]

On Mon, 2022-05-09 at 12:17 -0700, Carl Love wrote:
> Will, Pedro, Kevin, GDB maintainers:
> 
> Sorry, resend, the first attempt was missing the mailing list.
> 
> I have updated the patch per the comments from Will.  The new version
> of the patch uses a PowerPC specific gcc option to suppress the
> generation of the Traceback Table information.  The Traceback
> information is contained in the .long statements following the last
> instruction in the function.  Now the existing test to locate the last
> instruction in the function works without any changes.


In this cases the disassembly is presenting the traceback table
contents as .long values, but with an (un)lucky combination of bits, it
may also represent parts of that table as instructions.  Thats all
chance on which bits/fields are set.  That can show up readily with the
"-mtraceback=full" option, probably unlikely with the default trace
table contents.   (tldr; it won't always be represented as .long
0xfoo...).



> 
> Note, the use of the gcc mtraceback option is not valid on other
> architectures.
> 
> I have tested the patch on Power 10 and Intel.
> 
> Please let me know if this patch is acceptable.  Thanks for the input
> and help with the patch.
> 
>                           Carl Love
> -----------------------------------------------------------------
> 
> PowerPC: fix for gdb.base/eh_return.exp
> 


> Disable the Traceback Table generation on PowerPC.  The Traceback Table

  Disable ... for this test.

> consists of multiple .long statement following the final instruction in

The traceback table is being interpreted by the assembler as data and
is represented as .long by the disassembler that is looking for
instructions, but the table itself is a series of mostly bitfields.   


I'll suggest rephrasing, something like 


s/consists ... statements /is defined by the PowerPC ELF ABI and is
intended to support debuggers and exception handlers.  The Traceback
Table is located following the end of the code for every function. 

> the function.  Generation of the .long statements needs to be disabled with
> the PowerPC specific gcc compiler option -mtraceback=no so the test will
> correctly locate the address of the bclr instruction before the statement
> "End of assembler dump."



> ---
>  gdb/testsuite/gdb.base/eh_return.exp | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
> index df55dbc72da..3a49464af63 100644
> --- a/gdb/testsuite/gdb.base/eh_return.exp
> +++ b/gdb/testsuite/gdb.base/eh_return.exp
> @@ -18,8 +18,30 @@
> 
>  standard_testfile
> 
> +if {[istarget "powerpc*"]} then {
> +    # PowerPC generates a Traceback Table following each function by default.


Consider adding "as defined by the PPC64 ABIs" betwen Table and
Following. 


> +    # The .long statements following the function contain the Traceback Table
> +    # information.  For example:
> +    #   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.
> +    #
> +    # Disable the Traceback Table generation, using the PowerPC specific
> +    # gcc option, so the test gdb_test_multiple "disassemble eh2" will match
> +    # the blr instruction not the .long statement.
> +    set compile_flags {debug nopie additional_flags=-mtraceback=no}
> +} else {
> +    set compile_flags {debug nopie}
> +}

This seems OK to me, assuming this test is exercising a simple
scenario, versus representative of function elsewhere in the GDB code
base.  If there is a deeper issue that the traceback tables are causing
elsewhere in the GDB code base, some deeper solution may need to be
investigated. 


> +
>  if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
> -	 {debug nopie}]} {
> +	 $compile_flags]} {
>      return -1
>  }
> 

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

[Pedro Alves]

On 2022-05-09 21:57, will schmidt wrote:
> On Mon, 2022-05-09 at 12:17 -0700, Carl Love wrote:
>> Will, Pedro, Kevin, GDB maintainers:
>>
>> Sorry, resend, the first attempt was missing the mailing list.
>>
>> I have updated the patch per the comments from Will.  The new version
>> of the patch uses a PowerPC specific gcc option to suppress the
>> generation of the Traceback Table information.  The Traceback
>> information is contained in the .long statements following the last
>> instruction in the function.  Now the existing test to locate the last
>> instruction in the function works without any changes.
> 
> 
> In this cases the disassembly is presenting the traceback table
> contents as .long values, but with an (un)lucky combination of bits, it
> may also represent parts of that table as instructions.  Thats all
> chance on which bits/fields are set.  That can show up readily with the
> "-mtraceback=full" option, probably unlikely with the default trace
> table contents.   (tldr; it won't always be represented as .long
> 0xfoo...).


OOC, does the ABI specify that the size of the function covers the
Traceback information as well?  I didn't find anything about that, and my initial
reading of the wording used in the ABI "following the end of the code" would
make me think that it should not.  If it wasn't, then of course disassembling
a function would not run into the table.  Maybe it's done this way today to make it
easier on the linker.

Regardless, I was wondering whether there's any way for GDB to know that
a given PC range is a traceback table, so that it wouldn't try to disassemble
such a range as instructions?  The ABI you pointed out says:

"Compilers should generate a traceback table following the end of the code for every function. Debuggers
and exception handlers can locate the traceback tables by scanning forward from the instruction address
at the point of interruption. The beginning of the traceback table is marked by a word of zeroes, which is
an illegal instruction. If read-only constants are compiled into the same section as the function code, they
must follow the traceback table. A word of zeroes as read-only data must not be the first word following
the code for a function. A traceback table is word-aligned."

Naively, we could use the "word of zeroes" marker to see where the table starts, but it
wouldn't work when you're disassembling a PC range instead of the whole function.

Is there perhaps some symbol that points to the start of the table, or some section with the list
of traceback tables in the program or some such?

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

[Carl Love]

Will, Pedro, Kevin, GDB maintainers:

Sorry, resend, the first attempt was missing the mailing list.

I have updated the patch per the comments from Will.  The new version
of the patch uses a PowerPC specific gcc option to suppress the
generation of the Traceback Table information.  The Traceback
information for this function is contained in the .long statements
following the last instruction in the function.  The Traceback table
consists of a series of bit fields.  The assembler tries to interpret
the Traceback Table as instructions.  If the bits in the Traceback
Table happen to match a known instruction, the assembler will print a
bogus instruction, otherwise the assembler just prints the bits using
the .long statement.  Unfortunately, the disassembler does not know how
to locate the Traceback Table information at the end of a function.

With this patch, the existing gdb_test_multiple is able to locate the
last instruction in the function correctly.  Previously, the break
point was set at the last .long statement which gdb will never reach. 
The test now passes as gdb successfully executes to the identified last
instruction.

Note, the use of the gcc mtraceback option is not valid on other
architectures.

I have tested the patch on Power 10 and Intel.

Please let me know if this patch is acceptable.  Thanks for the input
and help with the patch.

                          Carl Love

-----------------------------------------------

PowerPC: fix for gdb.base/eh_return.exp

Disable the Traceback Table generation on PowerPC for this test.  The
Traceback Table consists of a series of bit fields to indicate things like
the Traceback Table version, language, and specific information about the
function.  The Traceback Table is generated following the end of the code
for every function by default.  The Traceback Table in the disassembly
output consists of the .long statements following the last instruction in
the function.  The Traceback Table is defined in the  PowerPC ELF ABI and
is intended to support debuggers and exception handlers.

Generation of the Traceback Table is disabled in this test using the
PowerPC specific gcc compiler option -mtraceback=no.  Disabling the
Traceback Table generation in this test results in the gdb_test_multiple
statement correctly locating the address of the bclr instruction before the
statement "End of assembler dump." in the disassembly output.
---
 gdb/testsuite/gdb.base/eh_return.exp | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
index df55dbc72da..13046df4040 100644
--- a/gdb/testsuite/gdb.base/eh_return.exp
+++ b/gdb/testsuite/gdb.base/eh_return.exp
@@ -18,8 +18,32 @@
 
 standard_testfile
 
+if {[istarget "powerpc*"]} then {
+    # PowerPC generates a Traceback Table, as defined in the PPC64 ABI,
+    # following each function by default.  The traceback table information is
+    # contained in the .long words output by the assembler following the last
+    # instruction in the function.  For example:
+    #
+    #   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.
+    #
+    # Disable the Traceback Table generation, using the PowerPC specific
+    # gcc option, so the test gdb_test_multiple "disassemble eh2" will match
+    # the blr instruction not the last .long statement.
+    set compile_flags {debug nopie additional_flags=-mtraceback=no}
+} else {
+    set compile_flags {debug nopie}
+}
+
 if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
-	 {debug nopie}]} {
+	 $compile_flags]} {
     return -1
 }
 
-- 
2.31.1

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

[Carl Love]

Pedro:

I reached out to the GCC team to see if I could get more information on
this.  I have inserted the answers to your questions below in your
reply.


On Tue, 2022-05-10 at 12:43 +0100, Pedro Alves wrote:
> On 2022-05-09 21:57, will schmidt wrote:
> > On Mon, 2022-05-09 at 12:17 -0700, Carl Love wrote:
> > > Will, Pedro, Kevin, GDB maintainers:
> > > 
> > > Sorry, resend, the first attempt was missing the mailing list.
> > > 
> > > I have updated the patch per the comments from Will.  The new
> > > version
> > > of the patch uses a PowerPC specific gcc option to suppress the
> > > generation of the Traceback Table information.  The Traceback
> > > information is contained in the .long statements following the
> > > last
> > > instruction in the function.  Now the existing test to locate the
> > > last
> > > instruction in the function works without any changes.
> > 
> > In this cases the disassembly is presenting the traceback table
> > contents as .long values, but with an (un)lucky combination of
> > bits, it
> > may also represent parts of that table as instructions.  Thats all
> > chance on which bits/fields are set.  That can show up readily with
> > the
> > "-mtraceback=full" option, probably unlikely with the default trace
> > table contents.   (tldr; it won't always be represented as .long
> > 0xfoo...).
> 
> OOC, does the ABI specify that the size of the function covers the
> Traceback information as well? 

The size of the function includes the traceback table.

>  I didn't find anything about that, and my initial
> reading of the wording used in the ABI "following the end of the
> code" would
> make me think that it should not.  If it wasn't, then of course
> disassembling
> a function would not run into the table.  Maybe it's done this way
> today to make it
> easier on the linker.
> 
> Regardless, I was wondering whether there's any way for GDB to know
> that
> a given PC range is a traceback table, so that it wouldn't try to
> disassemble
> such a range as instructions?  

GDB would have to determine the PC range of the traceback table.  You
start in the function and scan for a word of zeros that falls between
the function start address and the function start address plus the size
of the function.  So, if the traceback table was generated, you will
find a word of zeros.  In the case where the compiler flags were set to
not generate the traceback table, there will not be a word of zeros
before the function start address plus the size of the function.

> The ABI you pointed out says:
> 
> "Compilers should generate a traceback table following the end of the
> code for every function. Debuggers
> and exception handlers can locate the traceback tables by scanning
> forward from the instruction address
> at the point of interruption. The beginning of the traceback table is
> marked by a word of zeroes, which is
> an illegal instruction. If read-only constants are compiled into the
> same section as the function code, they
> must follow the traceback table. A word of zeroes as read-only data
> must not be the first word following
> the code for a function. A traceback table is word-aligned."
> 
> Naively, we could use the "word of zeroes" marker to see where the
> table starts, but it
> wouldn't work when you're disassembling a PC range instead of the
> whole function.

Basically you have to scan thru the function to find the word of zeros.

> 
> Is there perhaps some symbol that points to the start of the table, 

No

> or some section with the list
> of traceback tables in the program or some such?

Unfortunately the answer is again no.


I looked into the original problem report.  The issue had to do with
setting a break point on the last instruction in the function.  This
triggered an assert which was later fixed by commit 547ce8f00b
"[gdb/backtrace] Fix printing of fortran string args".  The commit adds
a call to select_frame in print_frame_args() in gdb/stack.c.  I tried
to dig into the specifics of how this change fixed the issue but I
don't see exactly how it fixed things.  Not sure knowing the details of
the fix is really necessary in this case, just interesting.

The test was added to check if the assert failed in the future due to
some code change.  The key thing is setting the break on the last
instruction in the function and verifying that gdb reaches the
breakpoint.  So, disabling the traceback table generation on PowerPC
allows the existing expect test to set the breakpoint on the last
instruction in the function, blr for PowerPC.  The test now behaves the
same on PowerPC as it does on other architectures.  I don't see that
not generating the traceback table on PowerPC would somehow invalidate
the ability of this test to verify the gdb code had not regressed.

I will fix up version 2 of the patch that disables the traceback table
per Will's comments and post version 3.

                           Carl Love

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

[Kevin Buettner]

On Wed, 11 May 2022 14:52:32 -0700
Carl Love <cel@us.ibm.com> wrote:

> +    # Disable the Traceback Table generation, using the PowerPC specific
> +    # gcc option, so the test gdb_test_multiple "disassemble eh2" will match

What happens when some compiler other than gcc is used to run the test?

Kevin

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

[Carl Love]

Kevin:

On Wed, 2022-05-11 at 15:48 -0700, Kevin Buettner wrote:
> On Wed, 11 May 2022 14:52:32 -0700
> Carl Love <cel@us.ibm.com> wrote:
> 
> > +    # Disable the Traceback Table generation, using the PowerPC
> > specific
> > +    # gcc option, so the test gdb_test_multiple "disassemble eh2"
> > will match
> 
> What happens when some compiler other than gcc is used to run the
> test?

Good question.  I hadn't considered other compilers that might be use. 
Guess I am a little to Linux centered.  So far, it looks like AIX, xlC
compiler uses -qtable=none, the LLVM compiler uses -mllvm -xcoff-
traceback-table=false, don't know about clang yet.  So, looks like the
test is going to need to check for Power, then walk thru the possible
compilers to set the needed option.

                      Carl 

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

[Carl Love]

Kevin:

On Wed, 2022-05-11 at 15:48 -0700, Kevin Buettner wrote:
> On Wed, 11 May 2022 14:52:32 -0700
> Carl Love <cel@us.ibm.com> wrote:
> 
> > +    # Disable the Traceback Table generation, using the PowerPC
> > specific
> > +    # gcc option, so the test gdb_test_multiple "disassemble eh2"
> > will match
> 
> What happens when some compiler other than gcc is used to run the
> test?

I updated the patch to set the compiler options for gcc and XLC.  The
test was run on AIX and passes with the patch.  Note that AIX actually
uses gcc to compile gdb.  We tried compiling gdb with the xlc compiler.
We ran into other gdb compilation errors that we were not able to
resolve.  We were able to verify that the xlc options to disable the
Traceback Buffer were right but that was it.  

If other compilers are used to compile gdb on power, the option for
that compiler to disable the Traceback Table will need to be added to
the test otherwise the test will fail for that compiler.

I will post the updated version of the patch.

                       Carl 

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

[Carl Love]

Will, Pedro, Kevin, GDB maintainers:

Per the comments from Kevin, the patch was updated to check for the gcc
and xlc compilers on PowerPC.  The patch was also tested and verified
on AIX which uses the gcc compiler to build gdb.  The attempt to build
gdb using the xlc compiler fails due to unrelated compiler errors.  The
xlc options to disable the Traceback Table was verified but that was
it.

I have updated the patch per the comments from Will.  The new version
of the patch uses a PowerPC specific gcc option to suppress the
generation of the Traceback Table information.  The Traceback
information for this function is contained in the .long statements
following the last instruction in the function.  The Traceback table
consists of a series of bit fields.  The assembler tries to interpret
the Traceback Table as instructions.  If the bits in the Traceback
Table happen to match a known instruction, the assembler will print a
bogus instruction, otherwise the assembler just prints the bits using
the .long statement.  Unfortunately, the disassembler does not know how
to locate the Traceback Table information at the end of a function.

With this patch, the existing gdb_test_multiple is able to locate the
last instruction in the function correctly.  Previously, the break
point was set at the last .long statement which gdb will never reach. 
The test now passes as gdb successfully executes to the identified last
instruction.

Note, the use of the gcc mtraceback option is not valid on other
architectures.

I have tested the patch on Linux Power 10 with gcc, AIX with the gcc
and Intel with gcc.

Please let me know if this patch is acceptable.  Thanks for the input
and help with the patch.

                          Carl Love

------------------------------------------------------------------

PowerPC: fix for gdb.base/eh_return.exp

Disable the Traceback Table generation on PowerPC for this test.  The
Traceback Table consists of a series of bit fields to indicate things like
the Traceback Table version, language, and specific information about the
function.  The Traceback Table is generated following the end of the code
for every function by default.  The Traceback Table is defined in the
PowerPC ELF ABI and is intended to support debuggers and exception
handlers.  The Traceback Table is displayed in the disassembly of functions
by default and is part of the function length.  The table is tyupically
interpreted by the disassembler as data represented by .long xxx entries.

Generation of the Traceback Table is disabled in this test using the
PowerPC specific gcc compiler option -mtraceback=no and the xlc option
additional_flags-qtable=none.  Disabling the Traceback Table generation in
this test results in the gdb_test_multiple statement correctly locating the
address of the bclr instruction before the statement "End of assembler
dump." in the disassembly output.
---
 gdb/testsuite/gdb.base/eh_return.exp | 35 +++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
index df55dbc72da..41d016486a1 100644
--- a/gdb/testsuite/gdb.base/eh_return.exp
+++ b/gdb/testsuite/gdb.base/eh_return.exp
@@ -18,8 +18,41 @@
 
 standard_testfile
 
+# Set compiler flags.
+if {[istarget "powerpc*"]} then {
+    # PowerPC generates a Traceback Table, as defined in the PPC64 ABI,
+    # following each function by default.  The Traceback Table information is
+    # typically interpreted by the disassembler as data represented with
+    # .long xxxx following the last instruction in the function.  For example:
+    #
+    #   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.
+    #
+    # Disable the Traceback Table generation, using the PowerPC specific
+    # compiler option, so the test gdb_test_multiple "disassemble eh2" will
+    # locate the address of the blr instruction not the last .long statement.
+    if { [test_compiler_info "gcc-*"] } {
+	set compile_flags {debug nopie additional_flags=-mtraceback=no}
+    } elseif { [test_compiler_info "xlc-*"] } {
+	set compile_flags {debug nopie additional_flags=-qtbtable=none}
+    } elseif { [test_compiler_info "clang-*"] } {
+	set compile_flags {debug nopie additional_flags=-mllvm -xcoff-traceback-table=false}
+    } else {
+	set compile_flags {debug nopie }
+    }
+} else {
+    set compile_flags {debug nopie}
+}
+
 if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
-	 {debug nopie}]} {
+	 $compile_flags]} {
     return -1
 }
 
-- 
2.31.1

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

[will schmidt]

On Thu, 2022-06-02 at 10:00 -0700, Carl Love wrote:
> Will, Pedro, Kevin, GDB maintainers:

> Per the comments from Kevin, the patch was updated to check for the gcc
> and xlc compilers on PowerPC.  The patch was also tested and verified
> on AIX which uses the gcc compiler to build gdb.  The attempt to build
> gdb using the xlc compiler fails due to unrelated compiler errors.  The
> xlc options to disable the Traceback Table was verified but that was
> it.

Ok.  A few troublesome words in there, but the gist is that AIX uses
GCC to build GDB, and the fix was verified using GCC.  Any problems on
AIX using XLC to build GDB are outside this scope.

I believe I've seen a comment that the TBT is not included in the
function size on AIX.  I've not directly inspected, but it may actually
be that AIX does not see the problem at all for that reason.


> 
> I have updated the patch per the comments from Will.  The new version
> of the patch uses a PowerPC specific gcc option to suppress the
> generation of the Traceback Table information.  The Traceback
> information for this function is contained in the .long statements
> following the last instruction in the function.  The Traceback table
> consists of a series of bit fields.  The assembler tries to interpret
> the Traceback Table as instructions.  If the bits in the Traceback
> Table happen to match a known instruction, the assembler will print a
> bogus instruction, otherwise the assembler just prints the bits using
> the .long statement.  Unfortunately, the disassembler does not know how
> to locate the Traceback Table information at the end of a function.

That could be reworked, but probably good enough.  :-)


> 
> With this patch, the existing gdb_test_multiple is able to locate the
> last instruction in the function correctly.  Previously, the break
> point was set at the last .long statement which gdb will never reach. 
> The test now passes as gdb successfully executes to the identified last
> instruction.

Consider "With this patch, the traceback table is disabled, so the last
instruction of the function is accurately found."



> 
> Note, the use of the gcc mtraceback option is not valid on other
> architectures.
> 
> I have tested the patch on Linux Power 10 with gcc, AIX with the gcc
> and Intel with gcc.
> 
> Please let me know if this patch is acceptable.  Thanks for the input
> and help with the patch.
> 
>                           Carl Love
> 
> ------------------------------------------------------------------
> 
> PowerPC: fix for gdb.base/eh_return.exp
> 
> Disable the Traceback Table generation on PowerPC for this test.  The
> Traceback Table consists of a series of bit fields to indicate things like
> the Traceback Table version, language, and specific information about the
> function.  The Traceback Table is generated following the end of the code
> for every function by default.  The Traceback Table is defined in the
> PowerPC ELF ABI and is intended to support debuggers and exception
> handlers.  The Traceback Table is displayed in the disassembly of functions
> by default and is part of the function length.  The table is tyupically
> interpreted by the disassembler as data represented by .long xxx entries.

s/tyup/typ/

> 
> Generation of the Traceback Table is disabled in this test using the
> PowerPC specific gcc compiler option -mtraceback=no and the xlc option
> additional_flags-qtable=none.  Disabling the Traceback Table generation in

And clang options "-mllvm -xcoff-traceback-table=false".




> this test results in the gdb_test_multiple statement correctly locating the
> address of the bclr instruction before the statement "End of assembler
> dump." in the disassembly output.
> ---
>  gdb/testsuite/gdb.base/eh_return.exp | 35 +++++++++++++++++++++++++++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
> index df55dbc72da..41d016486a1 100644
> --- a/gdb/testsuite/gdb.base/eh_return.exp
> +++ b/gdb/testsuite/gdb.base/eh_return.exp
> @@ -18,8 +18,41 @@
> 
>  standard_testfile
> 
> +# Set compiler flags.
> +if {[istarget "powerpc*"]} then {
> +    # PowerPC generates a Traceback Table, as defined in the PPC64 ABI,
> +    # following each function by default.  The Traceback Table information is
> +    # typically interpreted by the disassembler as data represented with
> +    # .long xxxx following the last instruction in the function.  For example:
> +    #
> +    #   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.
> +    #
> +    # Disable the Traceback Table generation, using the PowerPC specific
> +    # compiler option, so the test gdb_test_multiple "disassemble eh2" will
> +    # locate the address of the blr instruction not the last .long statement.
> +    if { [test_compiler_info "gcc-*"] } {
> +	set compile_flags {debug nopie additional_flags=-mtraceback=no}
> +    } elseif { [test_compiler_info "xlc-*"] } {
> +	set compile_flags {debug nopie additional_flags=-qtbtable=none}
> +    } elseif { [test_compiler_info "clang-*"] } {
> +	set compile_flags {debug nopie additional_flags=-mllvm -xcoff-traceback-table=false}

Does that work as-is?  I wonder if the -xcoff-traceback option should
have its own additional_flags=<foo> argument? 


> +    } else {
> +	set compile_flags {debug nopie }
> +    }
> +} else {
> +    set compile_flags {debug nopie}
> +}
> +
>  if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
> -	 {debug nopie}]} {
> +	 $compile_flags]} {

ok

Aside from the nits, this patch LGTM. 
Thanks,
-Will


>      return -1
>  }
> 

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

[Carl Love]

Will, Pedro, Kevin, GDB maintainers:

I have made the additional fixes to the comments and the setting of the
clang options as mentioned by Will in version 4.  I do not have an
environment where gdb can be built with clang.  But I did check that
the clang options are properly passed to the compile command. 
Unfortunately, extensive testing of gdb built with XLC and clang are
beyond the scope of this patch as I do not have access to such systems.

Per the comments from Kevin, the patch was updated to check for the gcc
and xlc compilers on PowerPC.  The patch was also tested and verified
on AIX which uses the gcc compiler to build gdb.  The attempt to build
gdb using the xlc compiler fails due to unrelated compiler errors.  The
xlc options to disable the Traceback Table was verified but that was
it.

I have updated the patch per the comments from Will.  The new version
of the patch uses a PowerPC specific gcc option to suppress the
generation of the Traceback Table information.  The Traceback
information for this function is contained in the .long statements
following the last instruction in the function.  The Traceback table
consists of a series of bit fields.  The assembler tries to interpret
the Traceback Table as instructions.  If the bits in the Traceback
Table happen to match a known instruction, the assembler will print a
bogus instruction, otherwise the assembler just prints the bits using
the .long statement.  Unfortunately, the disassembler does not know how
to locate the Traceback Table information at the end of a function.

With this patch, the Traceback Table is disabled, so the last
instruction of the function is accurately found.  Previously, the break
point was set at the last .long statement which gdb will never reach. 
The test now passes as gdb successfully executes to the identified last
instruction.

Note, the use of the gcc mtraceback option is not valid on other
architectures.

I have tested the patch on Linux Power 10 with gcc, AIX with the gcc
and Intel with gcc.

Please let me know if this patch is acceptable.  Thanks for the input
and help with the patch.

                          Carl Love

------------------------------------------------------------------

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

[Carl Love]

Will, Pedro, Kevin, GDB maintainers:

Oops, accidentally hit send.  Didn't get the patch attached yet.

I have made the additional fixes to the comments and the setting of the
clang options as mentioned by Will in version 4.  I do not have an
environment where gdb can be built with clang.  But I did check that
the clang options are properly passed to the compile command. 
Unfortunately, extensive testing of gdb built with XLC and clang are
beyond the scope of this patch as I do not have access to such systems.

Per the comments from Kevin, the patch was updated to check for the gcc
and xlc compilers on PowerPC.  The patch was also tested and verified
on AIX which uses the gcc compiler to build gdb.  The attempt to build
gdb using the xlc compiler fails due to unrelated compiler errors.  The
xlc options to disable the Traceback Table was verified but that was
it.

I have updated the patch per the comments from Will.  The new version
of the patch uses a PowerPC specific gcc option to suppress the
generation of the Traceback Table information.  The Traceback
information for this function is contained in the .long statements
following the last instruction in the function.  The Traceback table
consists of a series of bit fields.  The assembler tries to interpret
the Traceback Table as instructions.  If the bits in the Traceback
Table happen to match a known instruction, the assembler will print a
bogus instruction, otherwise the assembler just prints the bits using
the .long statement.  Unfortunately, the disassembler does not know how
to locate the Traceback Table information at the end of a function.

With this patch, the Traceback Table is disabled, so the last
instruction of the function is accurately found.  Previously, the break
point was set at the last .long statement which gdb will never reach. 
The test now passes as gdb successfully executes to the identified last
instruction.

Note, the use of the gcc mtraceback option is not valid on other
architectures.

I have tested the patch on Linux Power 10 with gcc, AIX with the gcc
and Intel with gcc.

Please let me know if this patch is acceptable.  Thanks for the input
and help with the patch.

                          Carl Love

------------------------------------------------------------------

PowerPC: fix for gdb.base/eh_return.exp

Disable the Traceback Table generation on PowerPC for this test.  The
Traceback Table consists of a series of bit fields to indicate things like
the Traceback Table version, language, and specific information about the
function.  The Traceback Table is generated following the end of the code
for every function by default.  The Traceback Table is defined in the
PowerPC ELF ABI and is intended to support debuggers and exception
handlers.  The Traceback Table is displayed in the disassembly of functions
by default and is part of the function length.  The table is typically
interpreted by the disassembler as data represented by .long xxx entries.

Generation of the Traceback Table is disabled in this test using the
PowerPC specific gcc compiler option -mtraceback=no, the xlc option
additional_flags-qtable=none and the clang optons
 -mllvm -xcoff-traceback-table=false.  Disabling the Traceback Table
generation in this test results in the gdb_test_multiple statement
correctly locating the address of the bclr instruction before the statement
"End of assembler dump." in the disassembly output.
---
 gdb/testsuite/gdb.base/eh_return.exp | 36 +++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
index df55dbc72da..6e4b9bd0bba 100644
--- a/gdb/testsuite/gdb.base/eh_return.exp
+++ b/gdb/testsuite/gdb.base/eh_return.exp
@@ -18,8 +18,42 @@
 
 standard_testfile
 
+# Set compiler flags.
+if {[istarget "powerpc*"]} then {
+    # PowerPC generates a Traceback Table, as defined in the PPC64 ABI,
+    # following each function by default.  The Traceback Table information is
+    # typically interpreted by the disassembler as data represented with
+    # .long xxxx following the last instruction in the function.  For example:
+    #
+    #   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.
+    #
+    # Disable the Traceback Table generation, using the PowerPC specific
+    # compiler option, so the test gdb_test_multiple "disassemble eh2" will
+    # locate the address of the blr instruction not the last .long statement.
+    if { [test_compiler_info "gcc-*"] } {
+	set compile_flags {debug nopie additional_flags=-mtraceback=no}
+    } elseif { [test_compiler_info "xlc-*"] } {
+	set compile_flags {debug nopie additional_flags=-qtbtable=none}
+    } elseif { [test_compiler_info "clang-*"] } {
+	set compile_flags [list debug nopie additional_flags=-mllvm \
+			       additional_flags=-xcoff-traceback-table=false]
+    } else {
+	set compile_flags {debug nopie }
+    }
+} else {
+    set compile_flags {debug nopie}
+}
+
 if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
-	 {debug nopie}]} {
+	 $compile_flags]} {
     return -1
 }
 
-- 
2.31.1

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

[will schmidt]

On Wed, 2022-06-08 at 08:36 -0700, Carl Love wrote:
> Will, Pedro, Kevin, GDB maintainers:
> 
> Oops, accidentally hit send.  Didn't get the patch attached yet.
> 
> I have made the additional fixes to the comments and the setting of the
> clang options as mentioned by Will in version 4.  I do not have an
> environment where gdb can be built with clang.  But I did check that
> the clang options are properly passed to the compile command. 
> Unfortunately, extensive testing of gdb built with XLC and clang are
> beyond the scope of this patch as I do not have access to such systems.
> 
> Per the comments from Kevin, the patch was updated to check for the gcc
> and xlc compilers on PowerPC.  The patch was also tested and verified
> on AIX which uses the gcc compiler to build gdb.  The attempt to build
> gdb using the xlc compiler fails due to unrelated compiler errors.  The
> xlc options to disable the Traceback Table was verified but that was
> it.
> 
> I have updated the patch per the comments from Will.  The new version
> of the patch uses a PowerPC specific gcc option to suppress the
> generation of the Traceback Table information.  The Traceback
> information for this function is contained in the .long statements
> following the last instruction in the function.  The Traceback table
> consists of a series of bit fields.  The assembler tries to interpret
> the Traceback Table as instructions.  If the bits in the Traceback
> Table happen to match a known instruction, the assembler will print a
> bogus instruction, otherwise the assembler just prints the bits using
> the .long statement.  Unfortunately, the disassembler does not know how
> to locate the Traceback Table information at the end of a function.
> 
> With this patch, the Traceback Table is disabled, so the last
> instruction of the function is accurately found.  Previously, the break
> point was set at the last .long statement which gdb will never reach. 
> The test now passes as gdb successfully executes to the identified last
> instruction.
> 
> Note, the use of the gcc mtraceback option is not valid on other
> architectures.
> 
> I have tested the patch on Linux Power 10 with gcc, AIX with the gcc
> and Intel with gcc.
> 
> Please let me know if this patch is acceptable.  Thanks for the input
> and help with the patch.
> 
>                           Carl Love
> 
> ------------------------------------------------------------------
> 
> PowerPC: fix for gdb.base/eh_return.exp
> 
> Disable the Traceback Table generation on PowerPC for this test.  The
> Traceback Table consists of a series of bit fields to indicate things like
> the Traceback Table version, language, and specific information about the
> function.  The Traceback Table is generated following the end of the code
> for every function by default.  The Traceback Table is defined in the
> PowerPC ELF ABI and is intended to support debuggers and exception
> handlers.  The Traceback Table is displayed in the disassembly of functions
> by default and is part of the function length.  The table is typically
> interpreted by the disassembler as data represented by .long xxx entries.
> 
> Generation of the Traceback Table is disabled in this test using the
> PowerPC specific gcc compiler option -mtraceback=no, the xlc option
> additional_flags-qtable=none and the clang optons
>  -mllvm -xcoff-traceback-table=false.  Disabling the Traceback Table
> generation in this test results in the gdb_test_multiple statement
> correctly locating the address of the bclr instruction before the statement
> "End of assembler dump." in the disassembly output.
> ---
>  gdb/testsuite/gdb.base/eh_return.exp | 36 +++++++++++++++++++++++++++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/eh_return.exp b/gdb/testsuite/gdb.base/eh_return.exp
> index df55dbc72da..6e4b9bd0bba 100644
> --- a/gdb/testsuite/gdb.base/eh_return.exp
> +++ b/gdb/testsuite/gdb.base/eh_return.exp
> @@ -18,8 +18,42 @@
> 
>  standard_testfile
> 
> +# Set compiler flags.
> +if {[istarget "powerpc*"]} then {
> +    # PowerPC generates a Traceback Table, as defined in the PPC64 ABI,
> +    # following each function by default.  The Traceback Table information is
> +    # typically interpreted by the disassembler as data represented with
> +    # .long xxxx following the last instruction in the function.  For example:
> +    #
> +    #   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.
> +    #
> +    # Disable the Traceback Table generation, using the PowerPC specific
> +    # compiler option, so the test gdb_test_multiple "disassemble eh2" will
> +    # locate the address of the blr instruction not the last .long statement.
> +    if { [test_compiler_info "gcc-*"] } {
> +	set compile_flags {debug nopie additional_flags=-mtraceback=no}
> +    } elseif { [test_compiler_info "xlc-*"] } {
> +	set compile_flags {debug nopie additional_flags=-qtbtable=none}
> +    } elseif { [test_compiler_info "clang-*"] } {
> +	set compile_flags [list debug nopie additional_flags=-mllvm \
> +			       additional_flags=-xcoff-traceback-table=false]
> +    } else {
> +	set compile_flags {debug nopie }
> +    }
> +} else {
> +    set compile_flags {debug nopie}
> +}
> +
>  if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
> -	 {debug nopie}]} {
> +	 $compile_flags]} {
>      return -1
>  }


This looks good to me.  Thanks for the multiple iterations and updates.
I am not an approver but I recommend approval.  :-) 

Thanks
-Will


> 

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

[Pedro Alves]

On 2022-06-02 17:52, Carl Love wrote:
> Kevin:
> 
> On Wed, 2022-05-11 at 15:48 -0700, Kevin Buettner wrote:
>> On Wed, 11 May 2022 14:52:32 -0700
>> Carl Love <cel@us.ibm.com> wrote:
>>
>>> +    # Disable the Traceback Table generation, using the PowerPC
>>> specific
>>> +    # gcc option, so the test gdb_test_multiple "disassemble eh2"
>>> will match
>>
>> What happens when some compiler other than gcc is used to run the
>> test?
> 
> I updated the patch to set the compiler options for gcc and XLC.  The
> test was run on AIX and passes with the patch.  Note that AIX actually
> uses gcc to compile gdb.  We tried compiling gdb with the xlc compiler.
> We ran into other gdb compilation errors that we were not able to
> resolve.  We were able to verify that the xlc options to disable the
> Traceback Buffer were right but that was it.  

The compiler used to build gdb does not have to be the same used to
run tests.  You can build gdb with gcc as usual, and then run tests
with some other compiler, like:

 $ make check RUNTESTFLAGS="CC_FOR_TARGET=foo CXX_FOR_TARGET=foo++"

Pedro Alves

> 
> If other compilers are used to compile gdb on power, the option for
> that compiler to disable the Traceback Table will need to be added to
> the test otherwise the test will fail for that compiler.
> 
> I will post the updated version of the patch.

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

[Carl Love]

Pedro:

On Wed, 2022-06-08 at 19:32 +0100, Pedro Alves wrote:
> 
> The compiler used to build gdb does not have to be the same used to
> run tests.  You can build gdb with gcc as usual, and then run tests
> with some other compiler, like:
> 
>  $ make check RUNTESTFLAGS="CC_FOR_TARGET=foo CXX_FOR_TARGET=foo++"
> 

OK, I wasn't aware of that.  

I sent email to my contact in AIX to see if they can try that for me. 
Unfortunately, I wasn't able to get gdb compiled on AIX so the testing
of the patch was done my a person in the AIX team who is able to build
gdb on AIX with gcc.  Hopefully they will be able to do some more
testing for me.

                     Carl 

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

[Carl Love]

On Wed, 2022-06-08 at 19:32 +0100, Pedro Alves wrote:
> On 2022-06-02 17:52, Carl Love wrote:
> > Kevin:
> > 
> > On Wed, 2022-05-11 at 15:48 -0700, Kevin Buettner wrote:
> > > On Wed, 11 May 2022 14:52:32 -0700
> > > Carl Love <cel@us.ibm.com> wrote:
> > > 
> > > > +    # Disable the Traceback Table generation, using the
> > > > PowerPC
> > > > specific
> > > > +    # gcc option, so the test gdb_test_multiple "disassemble
> > > > eh2"
> > > > will match
> > > 
> > > What happens when some compiler other than gcc is used to run the
> > > test?
> > 
> > I updated the patch to set the compiler options for gcc and
> > XLC.  The
> > test was run on AIX and passes with the patch.  Note that AIX
> > actually
> > uses gcc to compile gdb.  We tried compiling gdb with the xlc
> > compiler.
> > We ran into other gdb compilation errors that we were not able to
> > resolve.  We were able to verify that the xlc options to disable
> > the
> > Traceback Buffer were right but that was it.  
> 
> The compiler used to build gdb does not have to be the same used to
> run tests.  You can build gdb with gcc as usual, and then run tests
> with some other compiler, like:
> 
>  $ make check RUNTESTFLAGS="CC_FOR_TARGET=foo CXX_FOR_TARGET=foo++"

I asked the AIX person about using gdb compiled with gdb but compiling
the test case with xlc.  Here is his reply:

   I used gcc to compile gdb as it’s not easy to compile gdb with xlc.
   To use the xlc for compiling test programs I have modified the site.exp 
   file with the Option “CC_FOR_TARGET” & “CXX_FOR_TARGET” to point to xlc 
   binary path along with proper CFLAGS & CXXFLAGS.
    
   I confirmed that for compiling the eh_return.c xlc compiler is being used.
    
   Here is the compilation output.
    
   builtin_spawn -ignore SIGHUP /opt/IBM/xlc/16.1.0/bin/xlc -q64 -g -O0 -w  
   -qdbgfmt=dwarf -c -g -o /.../gdb/testsuite/outputs/gdb.base/eh_return/eh_return0.o 
   /.../gdb/testsuite/gdb.base/eh_return.c

   But since test program eh_return.c was written with gcc in mind it wasn’t able
   to compile and giving the undefined error.  gdb compile failed, 
    ld: 0711-317 ERROR: Undefined symbol: .__builtin_eh_return.

So unfortunately, he wasn't able to actually run the gdb test but was
able to verify the compilation of the test.  

                  Carl Love

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

[Carl Love]

Ping?

On Wed, 2022-06-08 at 11:29 -0500, will schmidt wrote:
> 
> 
> This looks good to me.  Thanks for the multiple iterations and
> updates.
> I am not an approver but I recommend approval.  :-) 
> 
> Thanks
> -Wil

On Wed, 2022-06-08 at 08:36 -0700, Carl Love wrote:
> Will, Pedro, Kevin, GDB maintainers:
> 
> Oops, accidentally hit send.  Didn't get the patch attached yet.
> 
> I have made the additional fixes to the comments and the setting of
> the
> clang options as mentioned by Will in version 4.  I do not have an
> environment where gdb can be built with clang.  But I did check that
> the clang options are properly passed to the compile command. 
> Unfortunately, extensive testing of gdb built with XLC and clang are
> beyond the scope of this patch as I do not have access to such
> systems.
> 
> Per the comments from Kevin, the patch was updated to check for the
> gcc
> and xlc compilers on PowerPC.  The patch was also tested and verified
> on AIX which uses the gcc compiler to build gdb.  The attempt to
> build
> gdb using the xlc compiler fails due to unrelated compiler
> errors.  The
> xlc options to disable the Traceback Table was verified but that was
> it.
> 
> I have updated the patch per the comments from Will.  The new version
> of the patch uses a PowerPC specific gcc option to suppress the
> generation of the Traceback Table information.  The Traceback
> information for this function is contained in the .long statements
> following the last instruction in the function.  The Traceback table
> consists of a series of bit fields.  The assembler tries to interpret
> the Traceback Table as instructions.  If the bits in the Traceback
> Table happen to match a known instruction, the assembler will print a
> bogus instruction, otherwise the assembler just prints the bits using
> the .long statement.  Unfortunately, the disassembler does not know
> how
> to locate the Traceback Table information at the end of a function.
> 
> With this patch, the Traceback Table is disabled, so the last
> instruction of the function is accurately found.  Previously, the
> break
> point was set at the last .long statement which gdb will never
> reach. 
> The test now passes as gdb successfully executes to the identified
> last
> instruction.
> 
> Note, the use of the gcc mtraceback option is not valid on other
> architectures.
> 
> I have tested the patch on Linux Power 10 with gcc, AIX with the gcc
> and Intel with gcc.
> 
> Please let me know if this patch is acceptable.  Thanks for the input
> and help with the patch.
> 
>                           Carl Love
> 
> ------------------------------------------------------------------
> 
> PowerPC: fix for gdb.base/eh_return.exp
> 
> Disable the Traceback Table generation on PowerPC for this test.  The
> Traceback Table consists of a series of bit fields to indicate things
> like
> the Traceback Table version, language, and specific information about
> the
> function.  The Traceback Table is generated following the end of the
> code
> for every function by default.  The Traceback Table is defined in the
> PowerPC ELF ABI and is intended to support debuggers and exception
> handlers.  The Traceback Table is displayed in the disassembly of
> functions
> by default and is part of the function length.  The table is
> typically
> interpreted by the disassembler as data represented by .long xxx
> entries.
> 
> Generation of the Traceback Table is disabled in this test using the
> PowerPC specific gcc compiler option -mtraceback=no, the xlc option
> additional_flags-qtable=none and the clang optons
>  -mllvm -xcoff-traceback-table=false.  Disabling the Traceback Table
> generation in this test results in the gdb_test_multiple statement
> correctly locating the address of the bclr instruction before the
> statement
> "End of assembler dump." in the disassembly output.
> ---
>  gdb/testsuite/gdb.base/eh_return.exp | 36
> +++++++++++++++++++++++++++-
>  1 file changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/eh_return.exp
> b/gdb/testsuite/gdb.base/eh_return.exp
> index df55dbc72da..6e4b9bd0bba 100644
> --- a/gdb/testsuite/gdb.base/eh_return.exp
> +++ b/gdb/testsuite/gdb.base/eh_return.exp
> @@ -18,8 +18,42 @@
> 
>  standard_testfile
> 
> +# Set compiler flags.
> +if {[istarget "powerpc*"]} then {
> +    # PowerPC generates a Traceback Table, as defined in the PPC64
> ABI,
> +    # following each function by default.  The Traceback Table
> information is
> +    # typically interpreted by the disassembler as data represented
> with
> +    # .long xxxx following the last instruction in the
> function.  For example:
> +    #
> +    #   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.
> +    #
> +    # Disable the Traceback Table generation, using the PowerPC
> specific
> +    # compiler option, so the test gdb_test_multiple "disassemble
> eh2" will
> +    # locate the address of the blr instruction not the last .long
> statement.
> +    if { [test_compiler_info "gcc-*"] } {
> +	set compile_flags {debug nopie additional_flags=-mtraceback=no}
> +    } elseif { [test_compiler_info "xlc-*"] } {
> +	set compile_flags {debug nopie additional_flags=-qtbtable=none}
> +    } elseif { [test_compiler_info "clang-*"] } {
> +	set compile_flags [list debug nopie additional_flags=-mllvm \
> +			       additional_flags=-xcoff-traceback-
> table=false]
> +    } else {
> +	set compile_flags {debug nopie }
> +    }
> +} else {
> +    set compile_flags {debug nopie}
> +}
> +
>  if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
> -	 {debug nopie}]} {
> +	 $compile_flags]} {
>      return -1
>  }
> 

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

[Ulrich Weigand]

Carl Love <cel@us.ibm.com> wrote:

>PowerPC: fix for gdb.base/eh_return.exp

This is OK.

Thanks,
Ulrich