mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-02-11 13:02:10 +08:00
Luis Machado reported some regressions after I pushed recent core file related patches fixing BZ 25631: FAIL: gdb.base/corefile.exp: backtrace in corefile.exp FAIL: gdb.base/corefile.exp: core-file warning-free FAIL: gdb.base/corefile.exp: print func2::coremaker_local FAIL: gdb.base/corefile.exp: up in corefile.exp FAIL: gdb.base/corefile.exp: up in corefile.exp (reinit) This commit fixes these regressions. Thanks to Luis for testing an earlier version of the patch. (I was unable to reproduce these regressions in various test environments that I created.) Luis is testing in a docker container which is using the AUFS storage driver. It turns out that the kernel is placing docker host paths in the NT_FILE note instead of paths within the container. I've made a similar docker environment (though apparently not similar enough to reproduce the regressions). This is one of the paths that I see mentioned in the warning messages printed while loading the core file during NT_FILE note processing - note that I've shortened the path component starting with "d07c4": /var/lib/docker/aufs/diff/d07c4...21/lib/x86_64-linux-gnu/ld-2.27.so This is a path on the docker host; it does not exist in the container. In the docker container, this is the path: /lib/x86_64-linux-gnu/ld-2.27.so My first thought was to disable all NT_FILE mappings when any path was found to be bad. This would have caused GDB to fall back to accessing memory using the file stratum as it did before I added the NT_FILE note loading code. After further consideration, I realized that we could do better than this. For file-backed memory access, we can still use the NT_FILE mappings when available, and then attempt to access memory using the file stratum constrained to those address ranges corresponding to the "broken" mappings. In order to test it, I made some additions to corefile2.exp in which the test case's executable is renamed. The core file is then loaded; due to the fact that the executable has been renamed, those mappings will be unavailable. After loading the core file, the executable is renamed back to its original name at which point it is loaded using GDB's "file" command. The "interesting" tests are then run. These tests will print out values in file-backed memory regions along with mmap'd regions placed within/over the file-backed regions. Despite the fact that the executable could not be found during the NT_FILE note processing, these tests still work correctly due to the fact that memory is available from the file stratum combined with the fact that the broken NT_FILE mappings are used to prevent file-backed access outside of the "broken" mappings. gdb/ChangeLog: * corelow.c (unordered_set): Include. (class core_target): Add field 'm_core_unavailable_mappings'. (core_target::build_file_mappings): Print only one warning per inaccessible file. Add unavailable/broken mappings to m_core_unavailable_mappings. (core_target::xfer_partial): Call... (core_target::xfer_memory_via_mappings): New method. gdb/testsuite/ChangeLog: * gdb.base/corefile2.exp (renamed binfile): New tests. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.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.