* [RFC] Using bt command in async mode
@ 2008-04-01 2:08 Nick Roberts
2008-04-01 19:55 ` Tom Tromey
0 siblings, 1 reply; 11+ messages in thread
From: Nick Roberts @ 2008-04-01 2:08 UTC (permalink / raw)
To: gdb-patches
This patch allows the bt to be executed in async mode while the inferior is
executing. The idea being that the frontend can get a snapshot of what the
inferior is doing and update the UI. It's just a proof of concept, so I've
used linux_nat_async_events and my_waitpid directly but eventually these could
be made into target methods, of course.
If the general idea is agreeable, I would like to extend it to other commands
like "info locals", "info threads" etc.
An example session looks like this:
(gdb) maintenance set linux-async on
(gdb) r&
Starting program: /home/nickrob/donowt
(gdb) bt
#0 0x080483c9 in mysub1 () at donowt.c:12
#1 0x080483f7 in mysub () at donowt.c:22
#2 0x0804840f in main () at donowt.c:28
(gdb) interrupt
(gdb)
Program received signal SIGINT, Interrupt.
0x080483c9 in mysub1 () at donowt.c:12
12 if (i == 5)
(gdb) quit
The program is running. Quit anyway (and kill it)? (y or n) y
nickrob@kahikatea:~$
--
Nick http://www.inet.net.nz/~nickrob
2008-04-01 Nick Roberts <nickrob@snap.net.nz>
* stack.c (backtrace_command): Make it work in async mode when
the target is executing.
* top.c (execute_command): Enable bt command in async mode.
* inferior.h: New externs
* linux-nat.c (linux_nat_async_events, my_waitpid): Make
non-static.
*** stack.c 18 Mar 2008 08:32:24 +1200 1.164
--- stack.c 01 Apr 2008 12:58:57 +1200
*************** static void
*** 1285,1293 ****
backtrace_command (char *arg, int from_tty)
{
struct cleanup *old_chain = NULL;
! int fulltrace_arg = -1, arglen = 0, argc = 0;
struct backtrace_command_args btargs;
if (arg)
{
char **argv;
--- 1285,1306 ----
backtrace_command (char *arg, int from_tty)
{
struct cleanup *old_chain = NULL;
! int fulltrace_arg = -1, arglen = 0, argc = 0, restart = 0;
struct backtrace_command_args btargs;
+ if (target_executing)
+ {
+ int status, options, async_events_were_enabled;
+
+ /* Must be async to get here. */
+ async_events_were_enabled = linux_nat_async_events (0);
+ target_stop ();
+ my_waitpid (PIDGET (inferior_ptid), &status, 0);
+ if (async_events_were_enabled)
+ linux_nat_async_events (1);
+ restart = 1;
+ }
+
if (arg)
{
char **argv;
*************** backtrace_command (char *arg, int from_t
*** 1342,1347 ****
--- 1355,1363 ----
if (old_chain)
do_cleanups (old_chain);
+
+ if (restart)
+ continue_command ("&", 0);
}
static void
*** top.c 01 Apr 2008 13:47:11 +1200 1.137
--- top.c 01 Apr 2008 13:35:00 +1200
*************** execute_command (char *p, int from_tty)
*** 463,469 ****
&& strcmp (c->name, "pwd") != 0
&& strcmp (c->name, "show") != 0
&& strcmp (c->name, "info") != 0
! && strcmp (c->name, "interrupt") != 0)
error (_("Cannot execute this command while the target is running."));
/* Pass null arg rather than an empty one. */
--- 463,470 ----
&& strcmp (c->name, "pwd") != 0
&& strcmp (c->name, "show") != 0
&& strcmp (c->name, "info") != 0
! && strcmp (c->name, "interrupt") != 0
! && strcmp (c->name, "bt") != 0)
error (_("Cannot execute this command while the target is running."));
/* Pass null arg rather than an empty one. */
*** inferior.h 30 Jan 2008 11:18:32 +1300 1.87
--- inferior.h 01 Apr 2008 09:24:04 +1200
*************** struct regcache;
*** 49,54 ****
--- 49,57 ----
struct inferior_status;
+ extern int my_waitpid (int pid, int *status, int flags);
+ extern int linux_nat_async_events (int enable);
+
extern struct inferior_status *save_inferior_status (int);
extern void restore_inferior_status (struct inferior_status *);
*** linux-nat.c 26 Mar 2008 08:51:33 +1200 1.80
--- linux-nat.c 01 Apr 2008 13:10:00 +1200
*************** static volatile int linux_nat_num_queued
*** 176,182 ****
target events are blocked. */
static int linux_nat_async_events_enabled;
- static int linux_nat_async_events (int enable);
static void pipe_to_local_event_queue (void);
static void local_event_queue_to_pipe (void);
static void linux_nat_event_pipe_push (int pid, int status, int options);
--- 176,181 ----
*************** linux_tracefork_child (void)
*** 350,356 ****
/* Wrapper function for waitpid which handles EINTR, and checks for
locally queued events. */
! static int
my_waitpid (int pid, int *status, int flags)
{
int ret;
--- 349,355 ----
/* Wrapper function for waitpid which handles EINTR, and checks for
locally queued events. */
! int
my_waitpid (int pid, int *status, int flags)
{
int ret;
*************** async_sigchld_handler (int signo)
*** 3820,3826 ****
/* Enable or disable async SIGCHLD handling. */
! static int
linux_nat_async_events (int enable)
{
int current_state = linux_nat_async_events_enabled;
--- 3819,3825 ----
/* Enable or disable async SIGCHLD handling. */
! int
linux_nat_async_events (int enable)
{
int current_state = linux_nat_async_events_enabled;
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFC] Using bt command in async mode 2008-04-01 2:08 [RFC] Using bt command in async mode Nick Roberts @ 2008-04-01 19:55 ` Tom Tromey 2008-04-01 22:30 ` Nick Roberts 2008-04-10 15:22 ` Daniel Jacobowitz 0 siblings, 2 replies; 11+ messages in thread From: Tom Tromey @ 2008-04-01 19:55 UTC (permalink / raw) To: Nick Roberts; +Cc: gdb-patches >>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes: Nick> This patch allows the bt to be executed in async mode while the Nick> inferior is executing. Nick> ! && strcmp (c->name, "interrupt") != 0 Nick> ! && strcmp (c->name, "bt") != 0) I've seen a couple patches recently that touch this conditional. What do you think of this? It moves the flag into the command object instead of hard-coding it into a big 'if'. I'm running the test suite now. Tom ChangeLog: 2008-04-01 Tom Tromey <tromey@redhat.com> * cli/cli-decode.h (CMD_ASYNC_OK): New define. (set_cmd_async_ok, get_cmd_async_ok): Declare. * cli/cli-decode.c (set_cmd_async_ok): New function. (get_cmd_async_ok): New function. * cli/cli-cmds.c (init_cli_cmds): Mark "pwd", "help", "info", and "show" as async-ok. * top.c (execute_command): Use get_cmd_async_ok. * infcmd.c: Include cli/cli-decode.h. (_initialize_infcmd): Mark "interrupt" as async-ok. * Makefile.in (infcmd.o): Depend on cli_decode_h. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.996 diff -u -r1.996 Makefile.in --- Makefile.in 26 Mar 2008 14:53:28 -0000 1.996 +++ Makefile.in 1 Apr 2008 18:38:21 -0000 @@ -2291,7 +2291,7 @@ $(objfiles_h) $(completer_h) $(ui_out_h) $(event_top_h) \ $(parser_defs_h) $(regcache_h) $(reggroups_h) $(block_h) \ $(solib_h) $(gdb_assert_h) $(observer_h) $(target_descriptions_h) \ - $(user_regs_h) $(exceptions_h) + $(user_regs_h) $(exceptions_h) $(cli_decode_h) inf-loop.o: inf-loop.c $(defs_h) $(inferior_h) $(target_h) $(event_loop_h) \ $(event_top_h) $(inf_loop_h) $(remote_h) $(exceptions_h) \ $(language_h) Index: infcmd.c =================================================================== RCS file: /cvs/src/src/gdb/infcmd.c,v retrieving revision 1.174 diff -u -r1.174 infcmd.c --- infcmd.c 17 Mar 2008 17:30:29 -0000 1.174 +++ infcmd.c 1 Apr 2008 18:38:21 -0000 @@ -49,6 +49,7 @@ #include "target-descriptions.h" #include "user-regs.h" #include "exceptions.h" +#include "cli/cli-decode.h" /* Functions exported for general use, in inferior.h: */ @@ -2326,8 +2327,9 @@ \"run\" command.")); set_cmd_completer (c, filename_completer); - add_com ("interrupt", class_run, interrupt_target_command, - _("Interrupt the execution of the debugged program.")); + c = add_com ("interrupt", class_run, interrupt_target_command, + _("Interrupt the execution of the debugged program.")); + set_cmd_async_ok (c); add_info ("registers", nofp_registers_info, _("\ List of integer registers and their contents, for selected stack frame.\n\ Index: top.c =================================================================== RCS file: /cvs/src/src/gdb/top.c,v retrieving revision 1.137 diff -u -r1.137 top.c --- top.c 23 Mar 2008 17:29:34 -0000 1.137 +++ top.c 1 Apr 2008 18:38:21 -0000 @@ -458,13 +458,8 @@ /* If the target is running, we allow only a limited set of commands. */ - if (target_can_async_p () && target_executing) - if (strcmp (c->name, "help") != 0 - && strcmp (c->name, "pwd") != 0 - && strcmp (c->name, "show") != 0 - && strcmp (c->name, "info") != 0 - && strcmp (c->name, "interrupt") != 0) - error (_("Cannot execute this command while the target is running.")); + if (target_can_async_p () && target_executing && !get_cmd_async_ok (c)) + error (_("Cannot execute this command while the target is running.")); /* Pass null arg rather than an empty one. */ arg = *p ? p : 0; Index: cli/cli-cmds.c =================================================================== RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v retrieving revision 1.73 diff -u -r1.73 cli-cmds.c --- cli/cli-cmds.c 1 Jan 2008 22:53:14 -0000 1.73 +++ cli/cli-cmds.c 1 Apr 2008 18:38:21 -0000 @@ -1202,8 +1202,9 @@ /* Define general commands. */ - add_com ("pwd", class_files, pwd_command, _("\ + c = add_com ("pwd", class_files, pwd_command, _("\ Print working directory. This is used for your program as well.")); + set_cmd_async_ok (c); c = add_cmd ("cd", class_files, cd_command, _("\ Set working directory to DIR for debugger and program being debugged.\n\ The change does not take effect for the program being debugged\n\ @@ -1243,6 +1244,7 @@ c = add_com ("help", class_support, help_command, _("Print list of commands.")); set_cmd_completer (c, command_completer); + set_cmd_async_ok (c); add_com_alias ("q", "quit", class_support, 1); add_com_alias ("h", "help", class_support, 1); @@ -1268,17 +1270,19 @@ show_history_expansion_p, &sethistlist, &showhistlist); - add_prefix_cmd ("info", class_info, info_command, _("\ + c = add_prefix_cmd ("info", class_info, info_command, _("\ Generic command for showing things about the program being debugged."), - &infolist, "info ", 0, &cmdlist); + &infolist, "info ", 0, &cmdlist); + set_cmd_async_ok (c); add_com_alias ("i", "info", class_info, 1); add_com ("complete", class_obscure, complete_command, _("List the completions for the rest of the line as a command.")); - add_prefix_cmd ("show", class_info, show_command, - _("Generic command for showing things about the debugger."), - &showlist, "show ", 0, &cmdlist); + c = add_prefix_cmd ("show", class_info, show_command, _("\ +Generic command for showing things about the debugger."), + &showlist, "show ", 0, &cmdlist); + set_cmd_async_ok (c); /* Another way to get at the same thing. */ add_info ("set", show_command, _("Show all GDB settings.")); Index: cli/cli-decode.c =================================================================== RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v retrieving revision 1.63 diff -u -r1.63 cli-decode.c --- cli/cli-decode.c 1 Jan 2008 22:53:14 -0000 1.63 +++ cli/cli-decode.c 1 Apr 2008 18:38:22 -0000 @@ -105,6 +105,18 @@ return cmd->context; } +void +set_cmd_async_ok (struct cmd_list_element *cmd) +{ + cmd->flags |= CMD_ASYNC_OK; +} + +int +get_cmd_async_ok (struct cmd_list_element *cmd) +{ + return cmd->flags & CMD_ASYNC_OK; +} + enum cmd_types cmd_type (struct cmd_list_element *cmd) { Index: cli/cli-decode.h =================================================================== RCS file: /cvs/src/src/gdb/cli/cli-decode.h,v retrieving revision 1.27 diff -u -r1.27 cli-decode.h --- cli/cli-decode.h 1 Jan 2008 22:53:14 -0000 1.27 +++ cli/cli-decode.h 1 Apr 2008 18:38:22 -0000 @@ -48,6 +48,9 @@ #define DEPRECATED_WARN_USER 0x2 #define MALLOCED_REPLACEMENT 0x4 +/* This flag is set if the command is allowed during async execution. */ +#define CMD_ASYNC_OK 0x8 + struct cmd_list_element { /* Points to next command in this list. */ @@ -243,6 +246,13 @@ extern void set_cmd_context (struct cmd_list_element *cmd, void *context); extern void *get_cmd_context (struct cmd_list_element *cmd); +/* Mark command as async-ready; there is no way to disable this once + set. */ +extern void set_cmd_async_ok (struct cmd_list_element *); + +/* Return true if command is async-ok. */ +extern int get_cmd_async_ok (struct cmd_list_element *); + extern struct cmd_list_element *lookup_cmd (char **, struct cmd_list_element *, char *, int, int); ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-01 19:55 ` Tom Tromey @ 2008-04-01 22:30 ` Nick Roberts 2008-04-10 16:05 ` Vladimir Prus 2008-04-10 15:22 ` Daniel Jacobowitz 1 sibling, 1 reply; 11+ messages in thread From: Nick Roberts @ 2008-04-01 22:30 UTC (permalink / raw) To: tromey; +Cc: gdb-patches > Nick> This patch allows the bt to be executed in async mode while the > Nick> inferior is executing. > > Nick> ! && strcmp (c->name, "interrupt") != 0 > Nick> ! && strcmp (c->name, "bt") != 0) > > I've seen a couple patches recently that touch this conditional. > > What do you think of this? It moves the flag into the command object > instead of hard-coding it into a big 'if'. Sure, the list will only get longer. In the long run it might be a good idea to add an argument to add_cmd and related functions. Incidentally, the patch I've presented for bt isn't suitable for inclusion as it uses: + + if (restart) + continue_command ("&", 0); If the user interrupts with 'bt' during a step, he presumably wants the step to finish. I'm not sure how easy it is for Gdb to jump the inferior back into it's old state of execution. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-01 22:30 ` Nick Roberts @ 2008-04-10 16:05 ` Vladimir Prus 2008-04-11 22:55 ` Nick Roberts 0 siblings, 1 reply; 11+ messages in thread From: Vladimir Prus @ 2008-04-10 16:05 UTC (permalink / raw) To: gdb-patches Nick Roberts wrote: > > Nick> This patch allows the bt to be executed in async mode while the > > Nick> inferior is executing. > > > > Nick> ! && strcmp (c->name, "interrupt") != 0 > > Nick> ! && strcmp (c->name, "bt") != 0) > > > > I've seen a couple patches recently that touch this conditional. > > > > What do you think of this? It moves the flag into the command object > > instead of hard-coding it into a big 'if'. > > Sure, the list will only get longer. In the long run it might be a good > idea to add an argument to add_cmd and related functions. > > Incidentally, the patch I've presented for bt isn't suitable for inclusion > as it uses: > > + > + if (restart) > + continue_command ("&", 0); > > If the user interrupts with 'bt' during a step, he presumably wants the step to > finish. I'm not sure how easy it is for Gdb to jump the inferior back into > it's old state of execution. It's not very hard. You only need to hack continue_command not to call (indirectly) the clear_proceed_status function, which currently wipes away all state. - Volodya ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-10 16:05 ` Vladimir Prus @ 2008-04-11 22:55 ` Nick Roberts 0 siblings, 0 replies; 11+ messages in thread From: Nick Roberts @ 2008-04-11 22:55 UTC (permalink / raw) To: Vladimir Prus; +Cc: gdb-patches > > Incidentally, the patch I've presented for bt isn't suitable for inclusion > > as it uses: > > > > + > > + if (restart) > > + continue_command ("&", 0); > > > > If the user interrupts with 'bt' during a step, he presumably wants the > > step to finish. I'm not sure how easy it is for Gdb to jump the inferior > > back into it's old state of execution. > > It's not very hard. You only need to hack continue_command not to call > (indirectly) the clear_proceed_status function, which currently wipes away > all state. It looks a bit harder than that. Perhaps the arguments proceed () was called with need to be saved, as well as executing the appropriate contination after proceed () returns. -- Nick http://www.inet.net.nz/~nickrob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-01 19:55 ` Tom Tromey 2008-04-01 22:30 ` Nick Roberts @ 2008-04-10 15:22 ` Daniel Jacobowitz 2008-04-10 15:36 ` Tom Tromey 1 sibling, 1 reply; 11+ messages in thread From: Daniel Jacobowitz @ 2008-04-10 15:22 UTC (permalink / raw) To: Tom Tromey; +Cc: Nick Roberts, gdb-patches On Tue, Apr 01, 2008 at 11:53:52AM -0600, Tom Tromey wrote: > What do you think of this? It moves the flag into the command object > instead of hard-coding it into a big 'if'. Seems like this will be just as awkward in the long term, but it's an improvement. OK if it tested fine. > ChangeLog: > 2008-04-01 Tom Tromey <tromey@redhat.com> > > * cli/cli-decode.h (CMD_ASYNC_OK): New define. > (set_cmd_async_ok, get_cmd_async_ok): Declare. > * cli/cli-decode.c (set_cmd_async_ok): New function. > (get_cmd_async_ok): New function. > * cli/cli-cmds.c (init_cli_cmds): Mark "pwd", "help", "info", and > "show" as async-ok. > * top.c (execute_command): Use get_cmd_async_ok. > * infcmd.c: Include cli/cli-decode.h. > (_initialize_infcmd): Mark "interrupt" as async-ok. > * Makefile.in (infcmd.o): Depend on cli_decode_h. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-10 15:22 ` Daniel Jacobowitz @ 2008-04-10 15:36 ` Tom Tromey 2008-04-10 15:39 ` Pedro Alves ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Tom Tromey @ 2008-04-10 15:36 UTC (permalink / raw) To: gdb-patches >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes: Daniel> Seems like this will be just as awkward in the long term, but Daniel> it's an improvement. Is there some other approach you'd prefer? Daniel> OK if it tested fine. I didn't run the test suite without the patch; I'll do that next week & check it in if it looks ok. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-10 15:36 ` Tom Tromey @ 2008-04-10 15:39 ` Pedro Alves 2008-04-17 2:58 ` Tom Tromey 2008-04-10 15:53 ` Daniel Jacobowitz 2008-04-17 2:47 ` Tom Tromey 2 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2008-04-10 15:39 UTC (permalink / raw) To: gdb-patches, Tom Tromey A Thursday 10 April 2008 16:22:36, Tom Tromey wrote: > >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes: > > Daniel> Seems like this will be just as awkward in the long term, but > Daniel> it's an improvement. > > Is there some other approach you'd prefer? > The approach I though of following would be to do it explicitly in each command, given that we may have commands that may apply to another thread not the current one in non-stop mode, prohibiting those commands early may be wrong. Something similar to ERROR_NO_INFERIOR. I'm not sure we're settled on --thread or not, so I didn't come forward with this. -- Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-10 15:39 ` Pedro Alves @ 2008-04-17 2:58 ` Tom Tromey 0 siblings, 0 replies; 11+ messages in thread From: Tom Tromey @ 2008-04-17 2:58 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb-patches >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes: >> Is there some other approach you'd prefer? Pedro> The approach I though of following would be to Pedro> do it explicitly in each command, given that we Pedro> may have commands that may apply to another thread Pedro> not the current one in non-stop mode, prohibiting those Pedro> commands early may be wrong. Pedro> Something similar to ERROR_NO_INFERIOR. Pedro> I'm not sure we're settled on --thread or not, so Pedro> I didn't come forward with this. I think this can still work with the patch I'm committing. A command that is ok for async could dynamically decide that it is not ok and throw an error. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-10 15:36 ` Tom Tromey 2008-04-10 15:39 ` Pedro Alves @ 2008-04-10 15:53 ` Daniel Jacobowitz 2008-04-17 2:47 ` Tom Tromey 2 siblings, 0 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2008-04-10 15:53 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches On Thu, Apr 10, 2008 at 09:22:36AM -0600, Tom Tromey wrote: > >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes: > > Daniel> Seems like this will be just as awkward in the long term, but > Daniel> it's an improvement. > > Is there some other approach you'd prefer? Not that I can think of. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] Using bt command in async mode 2008-04-10 15:36 ` Tom Tromey 2008-04-10 15:39 ` Pedro Alves 2008-04-10 15:53 ` Daniel Jacobowitz @ 2008-04-17 2:47 ` Tom Tromey 2 siblings, 0 replies; 11+ messages in thread From: Tom Tromey @ 2008-04-17 2:47 UTC (permalink / raw) To: gdb-patches >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Daniel> OK if it tested fine. Tom> I didn't run the test suite without the patch; I'll do that next week Tom> & check it in if it looks ok. I ran this and there were no regressions. I will check it in shortly. Tom ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-04-17 0:25 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-04-01 2:08 [RFC] Using bt command in async mode Nick Roberts 2008-04-01 19:55 ` Tom Tromey 2008-04-01 22:30 ` Nick Roberts 2008-04-10 16:05 ` Vladimir Prus 2008-04-11 22:55 ` Nick Roberts 2008-04-10 15:22 ` Daniel Jacobowitz 2008-04-10 15:36 ` Tom Tromey 2008-04-10 15:39 ` Pedro Alves 2008-04-17 2:58 ` Tom Tromey 2008-04-10 15:53 ` Daniel Jacobowitz 2008-04-17 2:47 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox