From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20237 invoked by alias); 13 Oct 2008 19:22:53 -0000 Received: (qmail 20223 invoked by uid 22791); 13 Oct 2008 19:22:51 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Oct 2008 19:22:14 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 5C1F84A00A; Mon, 13 Oct 2008 12:22:12 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost3.vmware.com (Postfix) with ESMTP id 51A37C9A26; Mon, 13 Oct 2008 12:22:12 -0700 (PDT) Message-ID: <48F39F2B.7040506@vmware.com> Date: Mon, 13 Oct 2008 19:22:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Joel Brobecker CC: "gdb-patches@sourceware.org" , Daniel Jacobowitz Subject: Re: [RFA] Resubmit, reverse debugging [0/5] References: <48EC1781.2030005@vmware.com> <48EF93A5.7060808@vmware.com> <20081010175332.GA9028@caradoc.them.org> <48EFA065.5070108@vmware.com> <20081011094636.GA3613@adacore.com> In-Reply-To: <20081011094636.GA3613@adacore.com> Content-Type: multipart/mixed; boundary="------------080709000807000603010403" 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: 2008-10/txt/msg00340.txt.bz2 This is a multi-part message in MIME format. --------------080709000807000603010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1085 Joel Brobecker wrote: >> OK, I agree -- but it's in use, in the field. > > I don't see this as a factor. If people want to use the version of the > protocol that has been deployed, then they can stick with the debugger > provided by the associated vendors. If they want to use the FSF GDB, > then they have to migrate. We're not suddenly dropping a feature that > we used to support. If we look at Ada as an example, there are several > features that AdaCore contributed which got redesigned as the result of > the review process. That meant that people using GPS (AdaCore's GUI) > would have some compatibility issues with the FSF GDB for a while, until > we enhanced GDB to recognize the way we implemented the given feature > for the FSF. We have done that a few times, now. > > Personally, after having had protocol compatibility issues between > a vendor-supplied gdbserver and our GDB, putting a new packet only to > remove it later is, IMO, asking for the same trouble again. OK, thanks guys -- I'll remove it. Revised patch attached. Is this perchance the final issue? --------------080709000807000603010403 Content-Type: text/plain; name="remote.e6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="remote.e6.txt" Content-length: 3228 2008-10-13 Michael Snyder * remote.c (remote_wait): Remove handling of "E6" no_history error. Recognize "replaylog" reply as part of 'T' stop event (NO_HISTORY). Declare "end of replay history" error reply as deprecated. Remote interface for reverse debugging. * remote.c (remote_can_execute_reverse): New target method. (remote_resume): Check for reverse exec direction, and send appropriate command to target. (remote_wait): Check target response for NO_HISTORY status. Also check for empty reply (target doesn't understand "bs" or "bc). (remote_vcont_resume): Jump out if attempting reverse execution. Index: remote.c =================================================================== RCS file: /cvs/src/src/gdb/remote.c,v retrieving revision 1.316 diff -u -p -r1.316 remote.c --- remote.c 10 Oct 2008 14:46:31 -0000 1.316 +++ remote.c 13 Oct 2008 19:06:21 -0000 @@ -3405,7 +3405,15 @@ remote_resume (ptid_t ptid, int step, en set_continue_thread (ptid); buf = rs->buf; - if (siggnal != TARGET_SIGNAL_0) + if (execution_direction == EXEC_REVERSE) + { + /* We don't pass signals to the target in reverse exec mode. */ + if (info_verbose && siggnal != TARGET_SIGNAL_0) + warning (" - Can't pass signal %d to target in reverse: ignored.\n", + siggnal); + strcpy (buf, step ? "bs" : "bc"); + } + else if (siggnal != TARGET_SIGNAL_0) { buf[0] = step ? 'S' : 'C'; buf[1] = tohex (((int) siggnal >> 4) & 0xf); @@ -3634,6 +3642,7 @@ remote_wait_as (ptid_t ptid, struct targ ptid_t event_ptid = null_ptid; ULONGEST addr; int solibs_changed = 0; + int replay_event = 0; char *buf, *p; status->kind = TARGET_WAITKIND_IGNORE; @@ -3749,6 +3758,16 @@ Packet: '%s'\n"), solibs_changed = 1; p = p_temp; } + else if (strncmp (p, "replaylog", p1 - p) == 0) + { + /* NO_HISTORY event. + p1 will indicate "begin" or "end", but + it makes no difference for now, so ignore it. */ + replay_event = 1; + p_temp = strchr (p1 + 1, ';'); + if (p_temp) + p = p_temp; + } else { /* Silently skip unknown optional info. */ @@ -3794,6 +3813,8 @@ Packet: '%s'\n"), case 'S': /* Old style status, just signal only. */ if (solibs_changed) status->kind = TARGET_WAITKIND_LOADED; + else if (replay_event) + status->kind = TARGET_WAITKIND_NO_HISTORY; else { status->kind = TARGET_WAITKIND_STOPPED; @@ -7615,6 +7636,14 @@ remote_command (char *args, int from_tty help_list (remote_cmdlist, "remote ", -1, gdb_stdout); } +static int remote_target_can_reverse = 1; + +static int +remote_can_execute_reverse (void) +{ + return remote_target_can_reverse; +} + static void init_remote_ops (void) { @@ -7663,6 +7692,7 @@ Specify the serial device it is connecte remote_ops.to_has_registers = 1; remote_ops.to_has_execution = 1; remote_ops.to_has_thread_control = tc_schedlock; /* can lock scheduler */ + remote_ops.to_can_execute_reverse = remote_can_execute_reverse; remote_ops.to_magic = OPS_MAGIC; remote_ops.to_memory_map = remote_memory_map; remote_ops.to_flash_erase = remote_flash_erase; --------------080709000807000603010403--