Luis Machado
1bd57575dc
The following failures started showing up after commitbb2a67773c- "Use a std::vector in target_section_table": FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[0]@4 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-4]@4 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[-3]@6 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_rw[pagesize-3]@6 FAIL: gdb.base/corefile2.exp: renamed binfile: print/x mbuf_ro[pagesize-3]@6 I tracked it down to a problem in core_target::xfer_partial, at this point: if (!m_core_file_mappings.empty ()) xfer_status = xfer_memory_via_mappings (readbuf, writebuf, offset, len, xfered_len); else xfer_status = this->beneath ()->xfer_partial (object, annex, readbuf, writebuf, offset, len, xfered_len); It seems commitbb2a67773cuncovered a latent bug when handling a particular case where things are running within a Docker container using the AUFS storage driver. When building the file mappings for a core file, we call gdbarch_read_core_file_mappings, which in turn passes a couple lambda callbacks. One pre-loop and one in-loop. The catch is that commitbb2a67773creworked the pre-loop lambda and made it do nothing. Before that commit, we always allocated m_core_file_mappings in that lambda. Now, when calling the in-loop lambda, we don't touch m_core_file_mappings because the bfd is nullptr (given Docker leaks the host system path, and that file doesn't exist within the container itself). So, instead, we add an entry to the m_core_unavailable_mappings vector. When we reach core_target::xfer_partial, we're only checking for an empty m_core_file_mappings. Given it is now empty, we take the path of reading the contents from the file, not the core file. This reads back unexpected results. The following patch fixes this by also checking for m_core_unavailable_mappings, given core_target::xfer_memory_via_mappings already handles the Docker/AUFS situation. gdb/ChangeLog: 2020-10-22 Luis Machado <luis.machado@linaro.org> * corelow.c (core_target::xfer_partial): Also check for an empty m_core_unavailable_mappings vector.
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.