mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-26 05:47:26 +08:00
d8c06f22a3
It was observed that in a multi-threaded application on GNU/Linux, that if the user has set the SIGSTOP to be pass (using GDB's handle command) then the inferior would hang upon hitting a breakpoint. What happens is that when a thread hits the breakpoint GDB tries to stop all of the other threads by sending them a SIGSTOP and setting the stop_requested flag in the target_ops structure - this can be seen in infrun.c:stop_all_threads. GDB then waits for all of the other threads to stop. When the SIGSTOP event arrives we eventually end up in linux-nat.c:linux_nat_filter_event, which has the job of deciding if the event we're looking at (the SIGSTOP arriving in this case) is something that should be reported back to the core of GDB. One of the final actions of this function is to check if we stopped due to a signal, and if we did, and the signal has been set to 'pass' by the user then we ignore the event and resume the thread. This code already has some conditions in place that mean the event is reported to GDB even if the signal is in the set of signals to be passed to the inferior. In this commit I extend this condition such that: If the signal is a SIGSTOP, and the thread's stop_requested flag is set (indicating we're waiting for the thread to stop with a SIGSTOP) then we should report this SIGSTOP to GDB and not pass it to the inferior. With this change in place the test now passes. Regression tested on x86-64 GNU/Linux with no regressions. gdb/ChangeLog: * linux-nat.c (linux_nat_filter_event): Don't ignore SIGSTOP if we have just sent the thread a SIGSTOP and are waiting for it to arrive. gdb/testsuite/ChangeLog: * gdb.threads/stop-with-handle.c: New file. * gdb.threads/stop-with-handle.exp: New file.
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.