mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-18 12:24:38 +08:00
c72f45d16c
Explation below based on what Joel wrote at: https://sourceware.org/ml/gdb-patches/2015-10/msg00274.html The merge async/sync code paths patch broke attaching on Windows. This is what we observe, after attaching to any process. At first, it seems like everything worked fine, since the process stops, and we get the prompt back: (gdb) att 3156 Attaching to program `C:\[...]\foo.exe', process 3156 [New Thread 3156.0xcd8] [New Thread 3156.0xfe4] 0x7770000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll (gdb) However, enter any commands at all, and GDB appears to be hanging. For instance: (gdb) set lang ada [nothing happens] Despite appearances, GDB is not reading from the prompt. It is blocked waiting for an event from the inferior. And since our inferior is stopped, there aren't going to be any events to read. In chronological order, what happens is that windows_attach calls do_initial_windows_stuff, which performs the inferior creation, and repeatedly waits until we get the first SIGTRAP: while (1) { stop_after_trap = 1; wait_for_inferior (); tp = inferior_thread (); if (tp->suspend.stop_signal != GDB_SIGNAL_TRAP) resume (tp->suspend.stop_signal); else break; } The call to wait_for_inferior triggers a call to do_target_wait to get the event, followed by handle_inferior_event to process it. However, because the first couple of events are "spurious" events, GDB resumes the execution, and prepares the inferior to wait again: case TARGET_WAITKIND_SPURIOUS: [...] resume (GDB_SIGNAL_0); prepare_to_wait (ecs); And prepare_to_wait just does... ecs->wait_some_more = 1; if (!target_is_async_p ()) mark_infrun_async_event_handler (); ... which as a result sets the infrun_async_event_handler "ready" flag to 1. We get a couple of spurious events before we get the initial SIGTRAP, at which point we exit the "while (1)" loop above, after which we reach the end of the attach_command, followed by the normal end-of-command processing (normal_stop, bp handling, printing the GDB prompt), back finally to the root of the event loop. Notice that, at this point, nothing has unset the "ready" flag for the infrun_async_event_handler. So, when another cycle of gdb_do_one_event from the event loop, we eventually call check_async_event_handlers, which finds that the infrun async event handler is "ready", and therefore calls it's associated "proc" callback, which does... inferior_event_handler (INF_REG_EVENT, NULL); ... triggering a blocking call to target_wait, thus hanging forever. The fix is to use windows_wait and windows_resume directly, similarly to gdbserver. This will also allow getting rid of 'stop_after_trap'. gdb/ChangeLog: 2015-10-22 Pedro Alves <palves@redhat.com> * windows-nat.c (do_initial_windows_stuff): Rewrite loop using windows_wait and windows_resume directly instead of wait_for_inferior and resume. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
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.