From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29443 invoked by alias); 24 Nov 2008 19:17:59 -0000 Received: (qmail 29397 invoked by uid 22791); 24 Nov 2008 19:17:58 -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; Mon, 24 Nov 2008 19:17:23 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id C84FD56001; Mon, 24 Nov 2008 11:17:13 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost2.vmware.com (Postfix) with ESMTP id A8B1B8E5E1; Mon, 24 Nov 2008 11:17:13 -0800 (PST) Message-ID: <492AFD8F.5000800@vmware.com> Date: Mon, 24 Nov 2008 21:54: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> 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/msg00657.txt.bz2 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? Is there another way to detect and avoid recording these changes?