mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-09 04:21:49 +08:00
dd9cd55e99
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.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| gprofng | ||
| include | ||
| intl | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.