From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14722 invoked by alias); 4 Mar 2009 03:42:12 -0000 Received: (qmail 14711 invoked by uid 22791); 4 Mar 2009 03:42:11 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14,J_CHICKENPOX_44,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.189) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Mar 2009 03:42:02 +0000 Received: by ti-out-0910.google.com with SMTP id y8so3132729tia.12 for ; Tue, 03 Mar 2009 19:41:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.110.52.5 with SMTP id z5mr8064877tiz.26.1236138119411; Tue, 03 Mar 2009 19:41:59 -0800 (PST) In-Reply-To: <200903032039.57204.pedro@codesourcery.com> References: <200903032039.57204.pedro@codesourcery.com> Date: Wed, 04 Mar 2009 03:42:00 -0000 Message-ID: Subject: Re: [RFA] Submit process record and replay third time, 3/9 From: teawater To: Pedro Alves Cc: gdb-patches@sourceware.org, Marc Khouzam Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2009-03/txt/msg00051.txt.bz2 Thanks Pedro, To get your mail is great for me. :) On Wed, Mar 4, 2009 at 04:39, Pedro Alves wrote: > Hi Hui, > > Sorry for the delay in getting back to this. > > On Monday 23 February 2009 09:20:13, teawater wrote: > >> --- >> =A0gdbarch.sh | =A0 =A04 ++++ >> =A01 file changed, 4 insertions(+) >> >> --- a/gdbarch.sh >> +++ b/gdbarch.sh >> @@ -709,6 +709,10 @@ F:char *:static_transform_name:char *nam >> =A0# Set if the address in N_SO or N_FUN stabs may be zero. >> =A0v:int:sofun_address_maybe_missing:::0:0::0 >> >> +# For the process record and replay target. >> +M:int:process_record:CORE_ADDR addr:addr > > You'll need to extend this comment a little further. =A0What is this > callback really for? =A0E.g., what is it supposed to do? =A0These things > should be documented here. What about the following: # Record a execution log of instruction at address addr. > > About the interface itself, would it be possible to adjust the > interface to make this callback's implementations not call record.c > functions, but instead have record.c work only with the results of > this callback? Are you mean i386_process_record doesn't call the function in record.c? That is so hard. A lot of this record is same for each arch. So I encapsulation them to be some function. For example, record_arch_list_add_reg and record_arch_list_add_mem. Another arch will need it in the future. So, do you think it's ok? > >> +M:void:process_record_dasm:void >> + > > I'm puzzled by this one. =A0What's this for? =A0I can't see it being > used anywhere, did I miss something? =A0What's "dasm"? =A0If its not > used for anything yet, let's remove it for now. > In replay mode, gdb will call gdbarch_process_record_dasm to let arch special code analyzes the current instruction and do some replay job. It will make record speed up and decrease the memory use. It just support by mips arch, but mips precord code is removed now. So I will removed it and add it back when some arch support it. By the way, process_record_dasm is so ugly name. Do you have some idea wit= h it? Thanks, Hui