mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 14:39:09 +08:00
677c92fe9a
target_ops::wait implementations should not rely on the value of inferior_ptid on entry. While looking at another wait-related patch, I noticed that the code in linux_nat_wait_1, checking for a newly created process, did just that. This patch fixes it. Note that I didn't see any bug, this "fix" is simply to make the function respect the target_ops::wait contract. Instead of checking inferior_ptid, check for the passed in `ptid` value. During startup, linux_nat_wait_1 gets called a few times with the pid-only ptid, while startup_inferior waits for the expected number of exec events. For this reason, I needed to add a `find_lwp_pid` call to ensure that the actions of changing the main thread's ptid, and adding the initial lwp, were done only once for a given process. This was not needed before, since thread_change_ptid, through the thread_ptid_changed observer, ends up changing inferior_ptid. So the second time around, inferior_ptid was not a pid-only ptid. That find_lwp_pid won't add much overhead, as it will only be called when the ptid is a pid-only ptid. And AFAIK, that only happens during inferior startup. An alternative to that `find_lwp_pid` call might be to make startup_inferior realize that the main thread has changed ptid, and make it wait for the new ptid. But that doesn't look easy to do. Regtested on amd64/Linux. gdb/ChangeLog: * linux-nat.c (linux_nat_wait_1): Don't use inferior_ptid when checking for initial lwp. Change-Id: I8f1d5c766f5cb2a29c948bc75fa4582d7130c23f
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.