From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32156 invoked by alias); 25 Nov 2008 18:23:42 -0000 Received: (qmail 32121 invoked by uid 22791); 25 Nov 2008 18:23:41 -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.43rc1) with ESMTP; Tue, 25 Nov 2008 18:23:05 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 0A0462300A; Tue, 25 Nov 2008 10:22:55 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost4.vmware.com (Postfix) with ESMTP id F3359C9ABA; Tue, 25 Nov 2008 10:22:54 -0800 (PST) Message-ID: <492C424A.7020203@vmware.com> Date: Wed, 26 Nov 2008 15:55:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: teawater CC: "gdb-patches@sourceware.org" Subject: Re: [RFA] Resubmit process record and replay, 6/10 References: <4924C39B.7040101@vmware.com> <492AFD8F.5000800@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-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-11/txt/msg00702.txt.bz2 teawater wrote: > On Tue, Nov 25, 2008 at 03:16, Michael Snyder wrote: >> teawater wrote: >>> Hi Michael, >>> >>> About "record_not_record_set", It set record_not_record to let P >>> record doesn't record the memory and registers control behaviors of >>> GDB in function record_store_registers and record_xfer_partial. >>> >>> So I think the name "record_not_record_set" and >>> "record_skip_recording" are not very clear. >>> Could you please give me some advices on it? >> Yeah, that's pretty much the way I understood it. >> >> It sets a one-time flag that says "omit (skip) recording >> registers and memory that would otherwise be recorded". >> >> And if I understand correctly, this is to avoid adding >> changes to the record log that are made by gdb when it >> resumes the target. It's only called from "proceed()". >> >> I'm not completely clear on what those changes are. >> Is gdb modifying the PC? Or are you perhaps trying to >> avoid recording breakpoints? > > I think avoid recording breakpoints is the main affect. > Another function is help deal with displaced step. Of course, P record > and displaced step will not work together now. > > I think I add "record_not_record" function is because I want > record_store_registers and record_xfer_partial just record the user > level change, not for others. > What do you think about it? OK, so if we ignore displaced stepping for now, then can we limit the issue to breakpoints? Breakpoint writes will all pass through functions called memory_insert_breakpoint and memory_remove_breakpoint (mem-break.c). So what we want to do is get the information from there into record.c. I guess you could do pretty much what you are doing now, only call the access function from mem-break.c instead of from infrun. It would help to localize it and make its meaning clear. Maybe call it "dont_record_memory_breakpoint" or something like that.