From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29928 invoked by alias); 6 Oct 2008 22:35:14 -0000 Received: (qmail 29919 invoked by uid 22791); 6 Oct 2008 22:35:13 -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, 06 Oct 2008 22:34:24 +0000 Received: (qmail 2200 invoked from network); 6 Oct 2008 22:34:22 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Oct 2008 22:34:22 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [RFA] Reverse Debugging, 1/5 Date: Mon, 06 Oct 2008 22:35:00 -0000 User-Agent: KMail/1.9.9 Cc: "gdb-patches@sourceware.org" , Joel Brobecker , Daniel Jacobowitz , teawater References: <48E3CCB6.4060501@vmware.com> <200810062245.31761.pedro@codesourcery.com> <48EA8D02.4030107@vmware.com> In-Reply-To: <48EA8D02.4030107@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810062334.55187.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-10/txt/msg00185.txt.bz2 On Monday 06 October 2008 23:11:14, Michael Snyder wrote: > Where I've been saying "target" in this thread, I > have been meaning "the target_ops implementation", > eg. (but not limited to) remote.c "target" is such an overloaded word in GDB lingo ... > > The question to me is --- when/why does the target (as in, the debug > > API abstraction) ever need to know about the current direction that > > it couldn't get from the core's request? > > At this interface layer, the core's requests look like: > > target_set_exec_dir > target_resume > target_wait > [repeat] > target_set_exec_dir > > So there may be many resume/wait calls between calls to set_exec_dir. > This means that the target_ops module MUST remember the state, whether > or not the core remembers it also. That's all nice and pretty, for sync. For async, you'll have: command target_set_exec_dir target_resume target_wait target_resume target_wait target_resume target_set_exec_dir At some point, if you support more than one inferior behind the target_ops interface, you'll start asking yourself "why didn't I make the interfaces fully complete and go rely on global state?" Or even, in the single-inferior case: command target_set_exec_dir target_resume target_wait target_resume target_set_exec_dir target_wait handle_inferior_event error >>>>>>>>>> what's the target execution >>>>>>>>>> state after this, where was it stored? But it's OK, we can always come back to this later, because you're making the remote protocol stateless, which is good enough for me for now. ;-) -- Pedro Alves