mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-05-31 10:09:16 +08:00
abc56d60aa
Currently, when remote debugging, if you type Ctrl-C just while the target stopped for an internal event, and GDB is busy doing something that takes a while (e.g., fetching chunks of a shared library off of the target, with vFile, to process ELF headers and debug info), the Ctrl-C is lost. The patch hooks up the QUIT macro to a new target method that lets the target react to the double-Ctrl-C before the event loop is reached, which allows reacting to a double-Ctrl-C even when GDB is busy doing some long operation and not waiting for a stop reply. That end result is: (gdb) c Continuing. ^C ^C Interrupted while waiting for the program. Give up waiting? (y or n) y Quit (gdb) info threads Id Target Id Frame * 1 Thread 11673 0x00007ffff7deb240 in _dl_debug_state () from target:/lib64/ld-linux-x86-64.so.2 (gdb) If, however, GDB is waiting for a stop reply (because the target has been resumed, with e.g., vCont;c), but the target isn't responding, we now get: (gdb) c Continuing. ^C ^C The target is not responding to interrupt requests. Stop debugging it? (y or n) y Disconnected from target. (gdb) info threads No threads. This offers to disconnect, because when we're waiting for a stop reply, there's nothing else we can send the target other than an interrupt request. And if that doesn't work, there's nothing else we can do. The Ctrl-C is presently lost because until we get to a user-visible stop, the SIGINT handler that is installed is the one that forwards the interrupt to the remote side, with the \003 "packet" [1]. But, gdbserver ignores an interrupt request if the program is stopped. Still, even if it didn't, the server can only report back a stop-because-of-SIGINT when the program is next resumed. And it may take a while to actually re-resume the target. [1] - In the old sync days, the remote target would react to a double-Ctrl-C by asking users whether they wanted to give up waiting and disconnect. The code is still there, but it it isn't reacheable on most hosts, which support serial connections in async mode (probably only DJGPP doesn't). Even then, in sync mode, remote.c's SIGINT handler is only installed while the target is resumed, and is removed as soon as the target sends back a stop reply. That means that a Ctrl-C just while GDB is processing an internal event can end up with an odd "Quit" at the prompt instead of "Program stopped by SIGINT". In contrast, in async mode, remote.c's SIGINT handler is set up as long as target_terminal_inferior or target_terminal_ours_for_output are in effect (IOW, until we get a user-visible stop and call target_terminal_ours), so the user shouldn't get back a spurious Quit. However, it's still desirable to be able to interrupt a long-running GDB operation, if GDB takes a while to re-resume the target or get back to the event loop. Tested on x86_64 Fedora 20. gdb/ChangeLog: 2015-08-24 Pedro Alves <palves@redhat.com> * defs.h (maybe_quit): Declare. (QUIT): Now calls maybe_quit. * event-loop.c (clear_async_signal_handler) (async_signal_handler_is_marked): New functions. * event-loop.h (async_signal_handler_is_marked) (clear_async_signal_handler): New declarations. * remote.c (remote_check_pending_interrupt): New function. (interrupt_query): Use make_cleanup_restore_target_terminal. No longer check whether the target is async. If waiting for a stop reply, and a Ctrl-C as been sent to the target, offer to disconnect, and throw TARGET_CLOSE_ERROR instead of a quit. Otherwise do not disconnect and throw a quit. (_initialize_remote): Install remote_check_pending_interrupt as to_check_pending_interrupt. * target.c (target_check_pending_interrupt): New function. * target.h (struct target_ops) <to_check_pending_interrupt>: New field. (target_check_pending_interrupt): New declaration. * utils.c (maybe_quit): New function. * target-delegates.c: Regenerate.
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.