From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30448 invoked by alias); 9 Jun 2008 00:52:30 -0000 Received: (qmail 30433 invoked by uid 22791); 9 Jun 2008 00:52:29 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jun 2008 00:52:03 +0000 Received: (qmail 11110 invoked from network); 9 Jun 2008 00:52:01 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Jun 2008 00:52:01 -0000 From: Pedro Alves To: teawater Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release Date: Mon, 09 Jun 2008 00:52:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org, "Michael Snyder" , "Thiago Jung Bauermann" References: <200805231746.23570.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <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/msg00149.txt.bz2 A Sunday 08 June 2008 07:53:14, teawater wrote: > Cool. This idea is so cool. > In before, I tried to make clear about the "strata", but I gave up. > Now, I know this thing is so cool. > But it let me very puzzled that which way is the best. > The way that I used in before, I have done a a lot of things on it. 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). > And it can be used. > The way that use a special target for record, I think this way look > professional. > Please tell me your idea about it. Thanks a lot. 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 | - (1) encapsulates the recording and replaying of events. Since record is on top, it answers the calls to target_can_reverse_p, target_wait, etc. In a remote debugging session, where the remote side does not support recording, it should be possible to do the recording in the GDB side: target | stratum | supports reverse | Notes -------------+------------------+--------------------+------------- record | record_statum | 1 | - remote | process_stratum | 0 | (2) exec target | file_stratum) | 0 | - (2) - GDB claims support for remote protocol reverse debugging extensions, but the remote side didn't support them. E.g.: Connect to an x86-linux gdbserver, and support reverse execution the same way you support recording native debugging. E.g., you may need to force single-stepping in record_resume, even if the upper layer didn't request it, I'd leave that to you :-) target | stratum | supports reverse | Notes -------------+------------------+--------------------+------------- remote | process_stratum | 1 | (3) exec target | file_stratum) | 0 | - (3) - GDB claims support for remote protocol reverse debugging extensions, and the remote side also claimed support. This would be the prefered method to support reverse execution when GDB is connected to a simulator or emulator. GDB would tell the remote "reverse step", and the remote end would take care of the reverse replaying. Another alternative, is to fold the record support into the process_stratum layer, but it doesn't look as clean: target | stratum | supports reverse | Notes -------------+------------------+--------------------+------------- linux native | process_stratum | 1 | (4) exec target | file_stratum) | 0 | - (4) Manages the recording and replaying itself, by defering to the record component. I'd prefer the separation into a new layer if it is possible at all. This imposes a requirement that the common code doesn't know about the record target's internals, but instead relies on target methods and properties. E.g. in infrun.c, instead of checking your record variables directly, you'd check for say, target_execution_direction () == EXEC_DIRECTION_REVERSE. I have no idea how feasible is this. This is just my gut feeling about it. As I said, take this as an investigation suggestion. :-) What do others think? -- Pedro Alves