From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12850 invoked by alias); 19 Oct 2009 18:11:43 -0000 Received: (qmail 12842 invoked by uid 22791); 19 Oct 2009 18:11:43 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 18:11:39 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 5717D130B9; Mon, 19 Oct 2009 11:11:38 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id 4EB0FC9B34; Mon, 19 Oct 2009 11:11:38 -0700 (PDT) Message-ID: <4ADCAA6B.5000606@vmware.com> Date: Mon, 19 Oct 2009 18:23:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Marc Khouzam CC: "'gdb@sourceware.org'" Subject: Re: [FYI] tutorial for process record and reverse debugging References: <4ADA4BD8.6080800@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00308.txt.bz2 Marc Khouzam wrote: >> -----Original Message----- >> From: gdb-owner@sourceware.org >> [mailto:gdb-owner@sourceware.org] On Behalf Of Michael Snyder >> Sent: Saturday, October 17, 2009 6:57 PM >> To: gdb@sourceware.org >> Subject: [FYI] tutorial for process record and reverse debugging >> >> FYI, there is now a tutorial for process record/replay and reverse >> debugging on the gdb wiki: >> >> http://sourceware.org/gdb/wiki/ProcessRecord/Tutorial > > Very clearly written. It should be very useful. > > I even learned that the following was a wanted behavior: > > "We can go directly to the point at which the recording currently ends, by disabling > all our breakpoints and then telling gdb to continue. Process record will replay > until it reaches the current end of the recording, and then stop." I don't know how well thought-out the current behavior is. It could be worth discussing. What I described in my tutorial is the behavior we've got, not necessarily the behavior we set out to achieve. > To be honest, I never cared much for this behavior because from an Eclipse > user-experience, it is not very clear why the execution/replay suddenly stops in > this case. OK, well, let's talk about it. Seems to me that if you're replaying, and you reach the end of the recorded log, at least one natural thing to do is to stop. Could be that another natural thing to do would be to automatically switch from replay mode to record mode and keep going -- but I'm not sure if I could safely assume that that was the user's desire. Sounds like a case for a query, and/or a user-settable mode. It sometimes seems to me that we have too many queries already, but maybe we can keep them under control with user-settable modes. Helpful to talk about them in advance, though... > But from reading the tutorial I see that it may be of interest in some situations. > What bothers me though is that one must disable all breakpoints and then re-enable > them. This can be a bit of an annoyance, especially if some bps were already disabled. > I got to wonder if this doesn't call for a new command; something like > "record live", which would take us to the end of the recording while not needing the > user to deal with existing breakpoints. Yeah, the "disable all breakpoints and continue" business was something that I just came up with on the spot. However, rather than such a specific command as you describe, I had been thinking about a more general alternative, which in my mind I have been referring to by the code name "goto". As in: (gdb) record goto end (gdb) record goto beginning (gdb) record goto instruction 12345 (gdb) record goto bookmark 7 Easy enough to make this command ignore breakpoints watchpoints etc.