public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: will schmidt <will_schmidt@vnet.ibm.com>,
	Pedro Alves <pedro@palves.net>,
	Kevin Buettner <kevinb@redhat.com>,
	gdb-patches@sourceware.org
Cc: Rogerio Alves <rogealve@br.ibm.com>, cel@us.ibm.com
Subject: Re: [PATCH V3] PowerPC: fix for gdb.base/eh_return.exp
Date: Wed, 11 May 2022 14:52:32 -0700	[thread overview]
Message-ID: <998d3f4859f16b73afd5103b682246643fef6d42.camel@us.ibm.com> (raw)
In-Reply-To: <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com>

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



  parent reply	other threads:[~2022-05-11 21:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 20:07 [PATCH] " Carl Love
2022-05-06 18:08 ` Kevin Buettner
2022-05-06 21:16   ` Pedro Alves
2022-05-06 22:45     ` will schmidt
2022-05-09 19:17       ` [PATCH V2] " Carl Love
2022-05-09 20:57         ` will schmidt
2022-05-10 11:43           ` Pedro Alves
2022-05-11 21:52             ` Carl Love
2022-05-11 21:52           ` Carl Love [this message]
2022-05-11 22:48             ` [PATCH V3] " Kevin Buettner
2022-05-12 16:00               ` Carl Love
2022-06-02 16:52               ` Carl Love
2022-06-08 18:32                 ` Pedro Alves
2022-06-08 18:51                   ` Carl Love
2022-06-09 15:24                   ` Carl Love
2022-06-02 17:00             ` [PATCH V4] " Carl Love
2022-06-07 17:54               ` will schmidt
2022-06-08 15:33                 ` [PATCH V5] " Carl Love
2022-06-08 15:36                   ` Carl Love
2022-06-08 16:29                     ` will schmidt
2022-07-13 17:07                     ` [Ping] " Carl Love
2022-07-15 13:41                     ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=998d3f4859f16b73afd5103b682246643fef6d42.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.com \
    --cc=pedro@palves.net \
    --cc=rogealve@br.ibm.com \
    --cc=will_schmidt@vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).