From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31757 invoked by alias); 5 Dec 2008 03:35:54 -0000 Received: (qmail 31747 invoked by uid 22791); 5 Dec 2008 03:35:53 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.191) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Dec 2008 03:35:04 +0000 Received: by ti-out-0910.google.com with SMTP id d10so2871613tib.12 for ; Thu, 04 Dec 2008 19:35:01 -0800 (PST) Received: by 10.110.43.16 with SMTP id q16mr22491181tiq.2.1228448101580; Thu, 04 Dec 2008 19:35:01 -0800 (PST) Received: by 10.110.43.10 with HTTP; Thu, 4 Dec 2008 19:35:01 -0800 (PST) Message-ID: Date: Fri, 05 Dec 2008 03:35:00 -0000 From: teawater To: "Michael Snyder" Subject: Re: [RFA] Resubmit process record and replay, 6/10 Cc: "gdb-patches@sourceware.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4924C39B.7040101@vmware.com> <492AFD8F.5000800@vmware.com> <492C424A.7020203@vmware.com> 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-12/txt/msg00090.txt.bz2 Hi Michael, Could you help me in http://sourceware.org/ml/gdb-patches/2008-11/msg00695.html Thanks, Hui On Wed, Nov 26, 2008 at 10:33, teawater wrote: > Sorry I forget a big part that need it. > When GDB work in replay mode, P record will set regs and memory in > record_wait. All of them can't be record. > > So what about set not_record flag to record_wait in replay mode, > record_insert_breakpoint and record_remove_breakpoint. > > And about the name of this flag, do you have some idea on it? > > > Thanks, > Hui > > > On Wed, Nov 26, 2008 at 02:22, Michael Snyder wrote: >> 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. >> >> >