From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2850 invoked by alias); 3 Mar 2009 20:40:01 -0000 Received: (qmail 2827 invoked by uid 22791); 3 Mar 2009 20:40:01 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14,J_CHICKENPOX_44,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 20:39:55 +0000 Received: (qmail 27580 invoked from network); 3 Mar 2009 20:39:53 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Mar 2009 20:39:53 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Submit process record and replay third time, 3/9 Date: Tue, 03 Mar 2009 20:40:00 -0000 User-Agent: KMail/1.9.10 Cc: teawater , Marc Khouzam References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903032039.57204.pedro@codesourcery.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: 2009-03/txt/msg00036.txt.bz2 Hi Hui, Sorry for the delay in getting back to this. On Monday 23 February 2009 09:20:13, teawater wrote: > --- > gdbarch.sh | 4 ++++ > 1 file changed, 4 insertions(+) > > --- a/gdbarch.sh > +++ b/gdbarch.sh > @@ -709,6 +709,10 @@ F:char *:static_transform_name:char *nam > # Set if the address in N_SO or N_FUN stabs may be zero. > v: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. What is this callback really for? E.g., what is it supposed to do? These things should be documented here. 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? > +M:void:process_record_dasm:void > + I'm puzzled by this one. What's this for? I can't see it being used anywhere, did I miss something? What's "dasm"? If its not used for anything yet, let's remove it for now. -- Pedro Alves