mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-24 04:00:07 +08:00
2a7f6487d0
When running test-case gdb.base/longjmp.exp with target board unix/-m32, we run into: ... (gdb) next^M Warning:^M Cannot insert breakpoint 0.^M Cannot access memory at address 0x7dbf7353^M ^M __libc_siglongjmp (env=0x804a040 <env>, val=1) at longjmp.c:28^M 28 longjmps++;^M (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) ... The failure to access memory happens in i386_get_longjmp_target and is due to glibc having pointer encryption (aka "pointer mangling" or "pointer guard") of the long jump buffer. This is a known problem. In create_longjmp_master_breakpoint (which attempts to install a master longjmp breakpoint) a preference scheme is present, which installs a probe breakpoint if a libc:longjmp probe is present, and otherwise falls back to setting breakpoints at the names in the longjmp_names array. But in fact, both the probe breakpoint and the longjmp_names breakpoints are set. The latter ones are set when processing libc.so.debug, and the former one when processing libc.so. In other words, this is the longjmp variant of PR26881, which describes the same problem for master exception breakpoints. This problem only triggers when the glibc debug info package is installed, which is not due to the debug info itself in libc.so.debug, but due to the minimal symbols (because create_longjmp_master_breakpoint uses minimal symbols to translate the longjmp_names to addresses). The problem doesn't trigger for -m64, because there tdep->jb_pc_offset is not set. Fix this similar to commit 1940319c0ef (the fix for PR26881): only install longjmp_names breakpoints in libc.so/libc.so.debug if installing the libc:longjmp probe in libc.so failed. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-28 Tom de Vries <tdevries@suse.de> PR breakpoints/27205 * breakpoint.c (create_longjmp_master_breakpoint_probe) (create_longjmp_master_breakpoint_names): New function, factored out of ... (create_longjmp_master_breakpoint): ... here. Only try to install longjmp_names breakpoints in libc.so/libc.so.debug if installing probe breakpoint in libc.so failed.
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.