From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13293 invoked by alias); 20 Apr 2006 19:58:30 -0000 Received: (qmail 13282 invoked by uid 22791); 20 Apr 2006 19:58:30 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 20 Apr 2006 19:58:26 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FWfIG-00063U-1u; Thu, 20 Apr 2006 15:58:24 -0400 Date: Thu, 20 Apr 2006 19:58:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: GDB Patches Subject: Re: [RFA] Reverse debugging, part 1/3: target interface Message-ID: <20060420195824.GC22563@nevyn.them.org> Mail-Followup-To: Michael Snyder , GDB Patches References: <442DAA70.5070203@redhat.com> <20060420135832.GD11710@nevyn.them.org> <4447E406.5050006@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4447E406.5050006@redhat.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00297.txt.bz2 On Thu, Apr 20, 2006 at 12:41:58PM -0700, Michael Snyder wrote: > > Also, it > >might be nice to use the new style rather than using INHERIT (search > >the vector at call time; see the "do not inherit" comments); that makes > >the debugging output nicer, too. > > OK, I think I know what you mean (the ->beneath business) -- > but why is this better? It's easier to deal with because we can figure out which target is implementing the method (e.g. if it wants to get at target-specific data). Also, "set debug target 1" takes effect right away if you do this - not the next time you connect. > >... but these _execution_direction methods. Please choose one or the > >other; it makes it simpler to find the uses and implementations at the > >same time. > > ... are you referring to the choices of names? > > I made the names of the macros more verbose because they're > more visible, and used in a context where any aid to understanding > is desireable. For the struct members themselves, I used shorter > names because they're *not* all that visible, are used in a context > where it's not all that critical to understand precisely what they > do, and longer names are cumbersome. For instance, they would make > the declarations in target.h really long. > > Do you still think I should change it? I do. The problem is, what are people going to call the target implementations of these? They implement target_get_execution_direction, but they get assigned to to_get_execdir. So whichever one you pick, some of the people searching for it aren't going to find it. I don't really care which one you use, though. > >>+ remote_ops.to_get_execdir = remote_get_execdir; > >>+ remote_ops.to_set_execdir = remote_set_execdir; > > > > > >What about the other remote ops vectors? At least one isn't copied > >from here. > > Right, well, I figured get it accepted in one vector, then > worry about extending it into others. Basically, as of this > patch, it will work with "target remote" only (and I guess > only in non-async mode). I guess. I really want to kill the extra vectors; but we can leave this as one more inconsistency to clean up between them. But the bits you're adding to remote.c don't seem that they'd need anything new to handle async. -- Daniel Jacobowitz CodeSourcery