1999-05-12 04:29:07 +08:00
|
|
|
/* Definitions used by the GDB event loop.
|
2020-01-01 14:20:01 +08:00
|
|
|
Copyright (C) 1999-2020 Free Software Foundation, Inc.
|
1999-05-12 04:29:07 +08:00
|
|
|
Written by Elena Zannoni <ezannoni@cygnus.com> of Cygnus Solutions.
|
|
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2007-08-24 02:08:50 +08:00
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
1999-05-12 04:29:07 +08:00
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
2007-08-24 02:08:50 +08:00
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
1999-05-12 04:29:07 +08:00
|
|
|
|
2019-01-28 03:51:36 +08:00
|
|
|
#ifndef EVENT_LOOP_H
|
|
|
|
|
#define EVENT_LOOP_H
|
|
|
|
|
|
2010-12-29 08:58:14 +08:00
|
|
|
/* An event loop listens for events from multiple event sources. When
|
1999-05-12 04:29:07 +08:00
|
|
|
an event arrives, it is queued and processed by calling the
|
2010-12-29 08:58:14 +08:00
|
|
|
appropriate event handler. The event loop then continues to listen
|
|
|
|
|
for more events. An event loop completes when there are no event
|
1999-05-12 04:29:07 +08:00
|
|
|
sources to listen on. External event sources can be plugged into
|
|
|
|
|
the loop.
|
|
|
|
|
|
2008-10-25 03:33:39 +08:00
|
|
|
There are 4 main components:
|
2010-12-29 08:58:14 +08:00
|
|
|
- a list of file descriptors to be monitored, GDB_NOTIFIER.
|
2008-10-25 03:33:39 +08:00
|
|
|
- a list of asynchronous event sources to be monitored,
|
|
|
|
|
ASYNC_EVENT_HANDLER_LIST.
|
2010-12-29 08:58:14 +08:00
|
|
|
- a list of events that have occurred, EVENT_QUEUE.
|
1999-05-12 04:29:07 +08:00
|
|
|
- a list of signal handling functions, SIGHANDLER_LIST.
|
|
|
|
|
|
2008-10-25 03:33:39 +08:00
|
|
|
GDB_NOTIFIER keeps track of the file descriptor based event
|
|
|
|
|
sources. ASYNC_EVENT_HANDLER_LIST keeps track of asynchronous
|
|
|
|
|
event sources that are signalled by some component of gdb, usually
|
|
|
|
|
a target_ops instance. Event sources for gdb are currently the UI
|
|
|
|
|
and the target. Gdb communicates with the command line user
|
|
|
|
|
interface via the readline library and usually communicates with
|
|
|
|
|
remote targets via a serial port. Serial ports are represented in
|
|
|
|
|
GDB as file descriptors and select/poll calls. For native targets
|
|
|
|
|
instead, the communication varies across operating system debug
|
|
|
|
|
APIs, but usually consists of calls to ptrace and waits (via
|
|
|
|
|
signals) or calls to poll/select (via file descriptors). In the
|
|
|
|
|
current gdb, the code handling events related to the target resides
|
|
|
|
|
in wait_for_inferior for synchronous targets; or, for asynchronous
|
|
|
|
|
capable targets, by having the target register either a target
|
|
|
|
|
controlled file descriptor and/or an asynchronous event source in
|
|
|
|
|
the event loop, with the fetch_inferior_event function as the event
|
|
|
|
|
callback. In both the synchronous and asynchronous cases, usually
|
|
|
|
|
the target event is collected through the target_wait interface.
|
|
|
|
|
The target is free to install other event sources in the event loop
|
|
|
|
|
if it so requires.
|
1999-05-12 04:29:07 +08:00
|
|
|
|
|
|
|
|
EVENT_QUEUE keeps track of the events that have happened during the
|
|
|
|
|
last iteration of the event loop, and need to be processed. An
|
|
|
|
|
event is represented by a procedure to be invoked in order to
|
|
|
|
|
process the event. The queue is scanned head to tail. If the
|
|
|
|
|
event of interest is a change of state in a file descriptor, then a
|
|
|
|
|
call to poll or select will be made to detect it.
|
|
|
|
|
|
|
|
|
|
If the events generate signals, they are also queued by special
|
|
|
|
|
functions that are invoked through traditional signal handlers.
|
|
|
|
|
The actions to be taken is response to such events will be executed
|
|
|
|
|
when the SIGHANDLER_LIST is scanned, the next time through the
|
2010-12-29 08:58:14 +08:00
|
|
|
infinite loop.
|
1999-05-12 04:29:07 +08:00
|
|
|
|
2010-12-29 08:58:14 +08:00
|
|
|
Corollary tasks are the creation and deletion of event sources. */
|
1999-05-12 04:29:07 +08:00
|
|
|
|
2000-03-03 23:37:09 +08:00
|
|
|
typedef void *gdb_client_data;
|
1999-10-06 07:13:56 +08:00
|
|
|
typedef void (handler_func) (int, gdb_client_data);
|
1999-09-22 11:28:34 +08:00
|
|
|
typedef void (timer_handler_func) (gdb_client_data);
|
1999-05-12 04:29:07 +08:00
|
|
|
|
1999-06-29 00:06:02 +08:00
|
|
|
/* Exported functions from event-loop.c */
|
1999-06-15 02:08:47 +08:00
|
|
|
|
2011-08-05 04:09:46 +08:00
|
|
|
extern int gdb_do_one_event (void);
|
1999-09-22 11:28:34 +08:00
|
|
|
extern void delete_file_handler (int fd);
|
2020-10-03 02:45:52 +08:00
|
|
|
|
|
|
|
|
/* Add a file handler/descriptor to the list of descriptors we are
|
|
|
|
|
interested in.
|
|
|
|
|
|
|
|
|
|
FD is the file descriptor for the file/stream to be listened to.
|
|
|
|
|
|
|
|
|
|
NAME is a user-friendly name for the handler. */
|
|
|
|
|
|
|
|
|
|
extern void add_file_handler (int fd, handler_func *proc,
|
|
|
|
|
gdb_client_data client_data,
|
|
|
|
|
std::string &&name);
|
|
|
|
|
|
2010-12-29 08:58:14 +08:00
|
|
|
extern int create_timer (int milliseconds,
|
|
|
|
|
timer_handler_func *proc,
|
|
|
|
|
gdb_client_data client_data);
|
1999-09-22 11:28:34 +08:00
|
|
|
extern void delete_timer (int id);
|
2008-03-06 01:21:10 +08:00
|
|
|
|
2020-04-14 02:42:59 +08:00
|
|
|
/* Must be defined by client. */
|
2008-03-06 01:21:10 +08:00
|
|
|
|
2020-04-14 02:42:59 +08:00
|
|
|
extern void handle_event_loop_exception (const gdb_exception &);
|
remote: allow aborting long operations (e.g., file transfers)
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.
2015-08-25 23:12:11 +08:00
|
|
|
|
2020-04-14 02:42:59 +08:00
|
|
|
/* Must be defined by client. Returns true if any signal handler was
|
|
|
|
|
ready. */
|
remote: allow aborting long operations (e.g., file transfers)
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.
2015-08-25 23:12:11 +08:00
|
|
|
|
2020-04-14 02:42:59 +08:00
|
|
|
extern int invoke_async_signal_handlers ();
|
remote: allow aborting long operations (e.g., file transfers)
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.
2015-08-25 23:12:11 +08:00
|
|
|
|
2020-04-14 02:42:59 +08:00
|
|
|
/* Must be defined by client. Returns true if any event handler was
|
|
|
|
|
ready. */
|
remote: allow aborting long operations (e.g., file transfers)
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.
2015-08-25 23:12:11 +08:00
|
|
|
|
2020-04-14 02:42:59 +08:00
|
|
|
extern int check_async_event_handlers ();
|
2019-01-28 03:51:36 +08:00
|
|
|
|
|
|
|
|
#endif /* EVENT_LOOP_H */
|
