From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7565 invoked by alias); 13 Jan 2010 13:16:29 -0000 Received: (qmail 7537 invoked by uid 22791); 13 Jan 2010 13:16:27 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 Jan 2010 13:16:23 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id AF57C26EEB6; Wed, 13 Jan 2010 14:16:20 +0100 (CET) Received: from polhem (unknown [62.20.90.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 908B126EEC8; Wed, 13 Jan 2010 14:16:19 +0100 (CET) From: "Jakob Engblom" To: "'Michael Snyder'" Cc: "'Vladimir Prus'" , , "'Hui Zhu'" References: <00ce01ca265a$ccb66ca0$662345e0$@com> <200912161056.58856.vladimir@codesourcery.com> <008f01ca7f26$d9e97140$8dbc53c0$@com> <200912211305.55412.vladimir@codesourcery.com> <00af01ca82fa$a8b74b60$fa25e220$@com> <4B310DBD.5000700@vmware.com> In-Reply-To: <4B310DBD.5000700@vmware.com> Subject: RE: GDB MI Reverse Commands added [1 of 3] Date: Wed, 13 Jan 2010 13:16:00 -0000 Message-ID: <00e501ca9452$9b47e610$d1d7b230$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00339.txt.bz2 I am now on parental leave, really, but I just gave it a try to try to get the MI reverse commands fixed. In particular, making them compatible with gdb7. We have an internal version at VT that does that, but that also contains the offending piece of code that is duplicated from reverse.c. In our code, and in the submitted patches, in mi-main.c, we have: ---- static void exec_continue (char **argv, int argc) { if (argc == 0) continue_1 (0); else if (argc == 1 && strcmp (argv[0], "--all") == 0) continue_1 (1); else if (argc == 2 && strcmp (argv[0], "--thread-group") == 0) { struct cleanup *old_chain; int pid; if (argv[1] == NULL || argv[1] == '\0') error ("Thread group id not specified"); pid = atoi (argv[1]); if (!in_inferior_list (pid)) error ("Invalid thread group id '%s'", argv[1]); old_chain = make_cleanup_restore_current_thread (); iterate_over_threads (proceed_thread_callback, &pid); do_cleanups (old_chain); } else error ("Usage: -exec-continue [--reverse] [--all|--thread-group id]"); } /* continue in reverse direction: XXX: code duplicated from reverse.c */ static void exec_direction_default (void *notused) { /* Return execution direction to default state. */ execution_direction = EXEC_FORWARD; } static void exec_reverse_continue (char **argv, int argc) { enum exec_direction_kind dir = execution_direction; struct cleanup *old_chain; if (dir == EXEC_ERROR) error (_("Target %s does not support this command."), target_shortname); if (dir == EXEC_REVERSE) error (_("Already in reverse mode.")); if (!target_can_execute_reverse) error (_("Target %s does not support this command."), target_shortname); old_chain = make_cleanup (exec_direction_default, NULL); execution_direction = EXEC_REVERSE; exec_continue (argv, argc); do_cleanups (old_chain); } void mi_cmd_exec_continue (char *command, char **argv, int argc) { if (argc > 0 && strcmp(argv[0], "--reverse") == 0) exec_reverse_continue (argv + 1, argc - 1); else exec_continue (argv, argc); } ---- This code is much more complex than for the other MI reverse commands, where the logic is very simple: ---- void mi_cmd_exec_step (char *command, char **argv, int argc) { /* FIXME: Should call a libgdb function, not a cli wrapper. */ if (argc > 0 && strcmp(argv[0], "--reverse") == 0) mi_execute_async_cli_command ("reverse-step", argv + 1, argc - 1); else mi_execute_async_cli_command ("step", argv, argc); } ---- To me, it is not clear why MI has to do such a special thing with the "continue" command at all. I assume there is a good reason for having the management of -all and -thread-group inside the MI code? Note that the standard gdb7 non-reversible MI does this for the continue command: ---- void mi_cmd_exec_continue (char *command, char **argv, int argc) { if (argc == 0) continue_1 (0); else if (argc == 1 && strcmp (argv[0], "--all") == 0) continue_1 (1); else if (argc == 2 && strcmp (argv[0], "--thread-group") == 0) { struct cleanup *old_chain; int pid; if (argv[1] == NULL || argv[1] == '\0') error ("Thread group id not specified"); pid = atoi (argv[1]); if (!in_inferior_list (pid)) error ("Invalid thread group id '%s'", argv[1]); old_chain = make_cleanup_restore_current_thread (); iterate_over_threads (proceed_thread_callback, &pid); do_cleanups (old_chain); } else error ("Usage: -exec-continue [--reverse] [--all|--thread-group id]"); } ---- Given this, the safest thing to do appears to be to maintain the current special handling for reverse continue. This works as a wrapper around the core code from mi_cmd_exec_continue, with an additional setting of direction before calling it. /jakob