mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-24 12:23:31 +08:00
bf93d7ba99
As mentioned in the previous patch, we should avoid doing register reads after a process does an exec and before we've updated that inferior's gdbarch. Otherwise, we may interpret the registers using the wrong architecture. When a process does an exec with "follow-exec-mode new", a new inferior is added by follow_exec. The gdbarch of that new inferior is at first set to some default value, probably specific to the gdb build (I get "i386" here), which may not be the right one. It is updated later by the call to target_find_description. Before that point, if we try to read the inferior's registers, we may not interpret them correctly. This has been exposed by a failure in gdb.base/foll-exec-mode.exp after the previous patch, with: Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes) The call to "add_thread" done just after adding the inferior is problematic, because it ends up reading the registers (because the ptid is re-used, we end up doing a switch_to_thread to it, which tries to update stop_pc). The registers returned by gdbserver are the x86-64 ones, while we try to interpret them using the "i386" gdbarch. Postponing the call to add_thread to until the target description/gdbarch has been updated seems to fix the issue. As to why this issue was uncovered by the previous patch: what I think happened before that patch is that since we were updating stop_pc before switching to the new inferior, we were filling the regcache associated to the ptid (this worked fine as long as the architectures of the previous and new process images were the same). The call to switch_to_thread then worked, because the register read hit the regcache. Now, it triggers a register read, while the gdbarch is not set correctly, leading to the "reply is too long" error. If this is right, it sounds wrong that we delete and re-add a thread with the same ptid, and are able to access the registers from the deleted thread. When we delete a thread, should we clear the regcache associated to that ptid, so that the new thread starts with a fresh/empty regcache? gdb/ChangeLog: * infrun.c (follow_exec): Call add_thread after target_find_description.
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.