John Baldwin
12e5b10965
I did not fully understand the requirements of multiple process support when I enabled it previously and several parts were broken. In particular, the resume method was only resuming a single process, and wait was not stopping other processes when reporting an event. To support multiple running inferiors, add a new per-inferior structure which trackes the number of existing and running LWPs for each process. The structure also stores a ptid_t describing the set of LWPs currently resumed for each process. For the resume method, iterate over all non-exited inferiors resuming each process matching the passed in ptid rather than only resuming the current inferior's process for a wildcard ptid. If a resumed process has a pending event, don't actually resume the process, but other matching processes without a pending event are still resumed in case the later call to the wait method requests an event from one of the processes without a pending event. For the wait method, stop other running processes before returning an event to the core. When stopping a process, first check to see if an event is already pending. If it is, queue the event to be reported later. If not, send a SIGSTOP to the process and wait for it to stop. If the event reported by the wait is not for the SIGSTOP, queue the event and remember to ignore a future SIGSTOP event for the process. Note that, unlike the Linux native target, entire processes are stopped rather than individual LWPs. In FreeBSD one can only wait on processes (via pid), not for an event from a specific thread. Other changes in this commit handle bookkeeping for the per-inferior data such as migrating the data to the new inferior in the follow_exec method. The per-inferior data is created in the attach, create_inferior, and follow_fork methods.
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.