From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1884 invoked by alias); 11 Jun 2008 07:46:01 -0000 Received: (qmail 1871 invoked by uid 22791); 11 Jun 2008 07:45:59 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.184) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jun 2008 07:45:36 +0000 Received: by ti-out-0910.google.com with SMTP id d10so774070tib.12 for ; Wed, 11 Jun 2008 00:45:33 -0700 (PDT) Received: by 10.110.15.9 with SMTP id 9mr1335516tio.50.1213170333651; Wed, 11 Jun 2008 00:45:33 -0700 (PDT) Received: by 10.110.109.4 with HTTP; Wed, 11 Jun 2008 00:45:33 -0700 (PDT) Message-ID: Date: Wed, 11 Jun 2008 11:59:00 -0000 From: teawater To: "Pedro Alves" Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release Cc: gdb-patches@sourceware.org, "Michael Snyder" , "Thiago Jung Bauermann" In-Reply-To: <200806090152.00220.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805231746.23570.pedro@codesourcery.com> <200806090152.00220.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: 2008-06/txt/msg00218.txt.bz2 Hi Pedro, > Don't worry, it's really more about code reorganization, than > rewriting. :-) > > You have two major components in your patch. > > 1 - The record/replay component > 2 - The inferior control in reverse execution mode. > > I'm suggesting to split those up, and make them communicate > with an abstracted interface (target methods). In addition, > make the record support a layer on top of the > forward-execution-only debugging targets (of course, defering > much to the arch support). > Michael Snyder is think about it too. He make a rev interface in before. I will try to use it. > My idea is that support for reverse execution should be exposed by > target methods and properties. Say target_can_reverse_p (), > target_set_execution_direction (...) or similar. For native > debugging, it might be possible to share most of the code > between similar targets. > > So, in a native linux debugging session, with record activated, the > target stack would look this (ignoring the thread layer), top to > bottom: > > target | stratum | supports reverse | Notes > -------------+------------------+--------------------+------------- > record | record_statum | 1 | (1) > linux native | process_stratum | 0 | - > exec target | file_stratum) | 0 | - > It's cool. But record only need the support of memory control and register control from target. So I think most of target can support record. For the speed up, I change the code of Linux-Nat. But other target such as "remote" still support by record. The record need most support is from GDBARCH. It need add a function like disassemble function in GDBARCH. I think make record to be a target is very cool idea. But to implement the current record. I have already changed a lot of code in GDB core part. After I make record to a target, I think it maybe will still have a lot of code in GDB core part. So make it to be a target is very important? Thanks, Hui