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

[will schmidt <will_schmidt@vnet.ibm.com>]

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