public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Carl Love <carll@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] PowerPC: bp-permanent.exp, kill-after-signal fix
Date: Fri,  6 May 2022 17:46:34 +0000 (GMT)	[thread overview]
Message-ID: <20220506174634.E8DC1395443F@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=dd9cd55e990bcc9f8448cac38d242d53974b3604

commit dd9cd55e990bcc9f8448cac38d242d53974b3604
Author: Carl Love <cel@us.ibm.com>
Date:   Fri May 6 17:45:58 2022 +0000

    PowerPC: bp-permanent.exp, kill-after-signal fix
    
    The break point after the stepi on Intel is the entry point of the user
    signal handler function test_signal_handler.  The code at the break point
    looks like:
    
         0x<hex address> <test_signal_handler>: endbr64
    
    On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
    after the stepi is in the vdso code inserted by the kernel.  The code at the
    breakpoint looks like:
    
      0x<hex address>  <__kernel_start_sigtramp_rt64>:      bctrl
    
    This is different from other architectures.  As discussed below, recent
    kernel changes involving the vdso for PowerPC have been made changes to the
    signal handler code flow.  PowerPC is now stopping in function
    __kernel_start_sigtramp_rt64.  PowerPC now requires an additional stepi to
    reach the user signal handler unlike other architectures.
    
    The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an
    kernel that is older than Linux 5.9.
    
    The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1:
    
        commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
        powerpc/64/signal: Balance return predictor stack in signal trampoline
    
    An additional change to the PowerPC 64 signal handler was made in Linux
    kernel version 5.11-rc7 :
    
         commit id: 24321ac668e452a4942598533d267805f291fdc9
         powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
    
    The first kernel change, puts code into the user space signal handler (in
    the vdso) as a performance optimization to prevent the call/return stack
    from getting out of balance.  The patch ensures that the entire
    user/kernel/vdso cycle is balanced with the addition of the "brctl"
    instruction.
    
    The second patch, fixes the semantics of __kernel_sigtramp_rt64().  A new
    symbol is introduced to serve as the jump target from the kernel to the
    trampoline which now consists of two parts.
    
    The above changes for PowerPC signal handler, causes gdb to stop in the
    kernel code not the user signal handler as expected.  The kernel dispatches
    to the vdso code which in turn calls into the signal handler.  PowerPC is
    special in that the kernel is using a vdso instruction (bctrl) to enter the
    signal handler.
    
    I do not have access to a system with the first patch but not the second.  I did
    test on Power 9 with the Linux 5.15.0-27-generic kernel.  Both tests fail on
    this Power 9 system.  The two tests also fail on Power 10 with the Linux
    5.14.0-70.9.1.el9_0.ppc64le kernel.
    
    The following patch fixes the issue by checking if gdb stopped at "signal
    handler called".  If gdb stopped there, the tests verifies gdb is in the kernel
    function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the
    user signal handler.  With the patch below, the tests run without errors on both
    the Power 9 and Power 10 systems with out any failures.

Diff:
---
 gdb/testsuite/gdb.base/bp-permanent.exp      | 25 +++++++++++++++++++++
 gdb/testsuite/gdb.base/kill-after-signal.exp | 33 +++++++++++++++++++++++++++-
 2 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp b/gdb/testsuite/gdb.base/bp-permanent.exp
index 8be46e96238..21b0bc7bb2d 100644
--- a/gdb/testsuite/gdb.base/bp-permanent.exp
+++ b/gdb/testsuite/gdb.base/bp-permanent.exp
@@ -260,6 +260,31 @@ proc test {always_inserted sw_watchpoint} {
 		    -re "Program received signal SIGTRAP.*$gdb_prompt $" {
 			fail $test
 		    }
+		    -re ".*signal handler called.*$gdb_prompt $" {
+			# PowerPC Linux kernel patchs:
+			#   commit: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
+			#   powerpc/64/signal: Balance return predictor
+			#   stack in signal trampoline.
+			#
+			# The kernel places an additional brctl instruction
+			# in the vdso to call the user hadler.
+			#
+			#   commit 24321ac668e452a4942598533d267805f291fdc9
+			#   powerpc/64/signal: Fix regression in
+			#   __kernel_sigtramp_rt64() semantics
+			#
+			# Updates the semantics of __kernel_sigtramp_rt64().
+			# It adds a new symbol to serve as a jump target from
+			# the kernel to the trampoline.
+			#
+			# The net result of these changes is that gdb stops
+			# at  __kernel_start_sigtramp_rt64.  Need to do one
+			# more stepi to reach the expected location in the user
+			# signal handler.
+			gdb_test "p \$pc" ".*__kernel_start_sigtramp_rt64.*" \
+			    "in kernel code"
+			gdb_test "stepi" "handler .*" $test
+		    }
 		    -re "handler .*$gdb_prompt $" {
 			pass $test
 		    }
diff --git a/gdb/testsuite/gdb.base/kill-after-signal.exp b/gdb/testsuite/gdb.base/kill-after-signal.exp
index 09f5cbc39a6..fcbec9a1c2e 100644
--- a/gdb/testsuite/gdb.base/kill-after-signal.exp
+++ b/gdb/testsuite/gdb.base/kill-after-signal.exp
@@ -36,7 +36,38 @@ if ![runto_main] {
 }
 
 gdb_test "continue" "Program received signal SIGUSR1, .*"
-gdb_test "stepi" "\r\nhandler .*"
+
+set test "handler"
+gdb_test_multiple "stepi" $test {
+    -re "\r\nhandler .*" {
+	pass $test
+    }
+    -re ".*signal handler called.*$gdb_prompt $" {
+	# PowerPC Linux kernel patchs:
+	#   commit: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
+	#   powerpc/64/signal: Balance return predictor
+	#   stack in signal trampoline.
+	#
+	# The kernel places an additional brctl instruction
+	# in the vdso to call the user hadler.
+	#
+	#   commit 24321ac668e452a4942598533d267805f291fdc9
+	#   powerpc/64/signal: Fix regression in
+	#   __kernel_sigtramp_rt64() semantics
+	#
+	# Updates the semantics of __kernel_sigtramp_rt64().
+	# It adds a new symbol to serve as a jump target from
+	# the kernel to the trampoline.
+	#
+	# The net result of these changes is that gdb stops
+	# at  __kernel_start_sigtramp_rt64.  Need to do one
+	# more stepi to reach the expected location in the user
+	# signal handler.
+	gdb_test "p \$pc" ".*__kernel_start_sigtramp_rt64.*" "in kernel code"
+	gdb_test "stepi" "\r\nhandler .*" $test
+    }
+}
+
 gdb_test_multiple "kill" "kill" {
     -re "Kill the program being debugged\\? \\(y or n\\) $" {
        gdb_test "y" "\\\[Inferior $decimal \\(.*\\) killed\\\]" "kill"


             reply	other threads:[~2022-05-06 17:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 17:46 Carl Love [this message]
2022-05-18 15:12 Carl Love

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=20220506174634.E8DC1395443F@sourceware.org \
    --to=carll@sourceware.org \
    --cc=gdb-cvs@sourceware.org \
    /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).