binutils-gdb modified for the FreeChainXenon project
db082f5979
In his reviews of my v1 and v2 corefile related patches, Pedro identified two cases which weren't handled by those patches. In https://sourceware.org/pipermail/gdb-patches/2020-May/168826.html, Pedro showed that debugging a core file in which mmap() is used to create a new mapping over an existing file-backed mapping will produce incorrect results. I.e, for his example, GDB would show: (gdb) disassemble main Dump of assembler code for function main: 0x00000000004004e6 <+0>: push %rbp 0x00000000004004e7 <+1>: mov %rsp,%rbp => 0x00000000004004ea <+4>: callq 0x4003f0 <abort@plt> End of assembler dump. This sort of looks like it might be correct, but is not due to the fact that mmap(...MAP_FIXED...) was used to create a mapping (of all zeros) on top of the .text section. So, the correct result should be: (gdb) disassemble main Dump of assembler code for function main: 0x00000000004004e6 <+0>: add %al,(%rax) 0x00000000004004e8 <+2>: add %al,(%rax) => 0x00000000004004ea <+4>: add %al,(%rax) 0x00000000004004ec <+6>: add %al,(%rax) 0x00000000004004ee <+8>: add %al,(%rax) End of assembler dump. The other case that Pedro found involved an attempted examination of a particular section in the test case from gdb.base/corefile.exp. On Fedora 27 or 28, the following behavior may be observed: (gdb) info proc mappings Mapped address spaces: Start Addr End Addr Size Offset objfile ... 0x7ffff7839000 0x7ffff7a38000 0x1ff000 0x1b5000 /usr/lib64/libc-2.27.so ... (gdb) x/4x 0x7ffff7839000 0x7ffff7839000: Cannot access memory at address 0x7ffff7839000 FYI, this section appears to be unrelocated vtable data. See https://sourceware.org/pipermail/gdb-patches/2020-May/168331.html for a detailed analysis. The important thing here is that GDB should be able to access this address since it should be backed by the shared library. I.e. it should do this: (gdb) x/4x 0x7ffff7839000 0x7ffff7839000: 0x0007ddf0 0x00000000 0x0007dba0 0x00000000 Both of these cases are fixed with this commit. In a nutshell, this commit opens a "binary" target BFD for each of the files that are mentioned in an NT_FILE / .note.linuxcore.file note section. It then uses these mappings instead of the file stratum mappings that GDB has used in the past. If this note section doesn't exist or is mangled for some reason, then GDB will use the file stratum as before. Should this happen, then we can expect both of the above problems to again be present. See the code comments in the commit for other details. gdb/ChangeLog: * corelow.c (solist.h, unordered_map): Include. (class core_target): Add field m_core_file_mappings and method build_file_mappings. (core_target::core_target): Call build_file_mappings. (core_target::~core_target): Free memory associated with m_core_file_mappings. (core_target::build_file_mappings): New method. (core_target::xfer_partial): Use m_core_file_mappings for memory transfers. * linux-tdep.c (linux_read_core_file_mappings): New function. (linux_core_info_proc_mappings): Rewrite to use linux_read_core_file_mappings. (linux_init_abi): Register linux_read_core_file_mappings. |
||
|---|---|---|
| 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 | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| lt~obsolete.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.