From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3404 invoked by alias); 2 Aug 2013 09:29:43 -0000 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 Received: (qmail 3384 invoked by uid 89); 2 Aug 2013 09:29:42 -0000 X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_05,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 02 Aug 2013 09:29:41 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r729TX9K025287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 05:29:33 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r729TVLs018945; Fri, 2 Aug 2013 05:29:32 -0400 Message-ID: <51FB7BFB.90100@redhat.com> Date: Fri, 02 Aug 2013 09:29:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: lgustavo@codesourcery.com CC: Tom Tromey , "'gdb-patches@sourceware.org'" Subject: Re: [PATCH] Refactor common/target-common into meaningful bits References: <51FA9649.5060008@codesourcery.com> <87vc3pfghs.fsf@fleche.redhat.com> <51FAA061.4050005@codesourcery.com> In-Reply-To: <51FAA061.4050005@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00065.txt.bz2 On 08/01/2013 06:52 PM, Luis Machado wrote: > On 08/01/2013 02:49 PM, Tom Tromey wrote: >>>>>>> "Luis" == Luis Machado writes: >> >> Luis> First, it seems like a good idea to stablish a more meaningful >> Luis> directory structure as well, so we are moving target-common.[c|h] from >> Luis> the "common" dir to the new "target" dir. This new directory will hold >> Luis> anything more backend-related. For now it contains only generic target >> Luis> definitions and functions. >> >> I like it. >> >> Luis> I've broken target-common.[c|h] into the following: >> Luis> - target-resume.h: Definition for resume_kind. >> Luis> - target-waitstatus.[c|h]: Definitions and code for anything related >> Luis> to waitstatus. >> Luis> - target-wait.h: A tiny bit that does not seem to fit properly in the >> Luis> waitstatus files, so it is left here. >> >> If I may be permitted to bikeshed just a bit longer... >> >> Right now the file is named "target/target-waitstatus.h" and the code >> says: >> >> +#include "target-waitstatus.h" >> >> >> I wonder whether you considered naming the file "target/waitstatus.h" >> and having the code say: > > I did and it does sound more intuitive, but i didn't want to turn too > many knobs at a time. If others are OK with this, i can make that change. We had a discussion on IRC yesterday on this. To sum it up: "target" is an overloaded word in GDB-speak. My idea for this new directory, would be for it to hold the native target backend bits. But "target" could also suggest that corelow.c, file.c, remote.c, etc. should be put in this directory, while I don't think they should. Sounds like a better name for this native target backend directory should be invented. GDB uses *-nat.c naming for most of these files, while GDBserver uses *-low.c. ( "low" itself in GDBserver is also ambiguous -- e.g., linux-low.h introduces the "struct linux_target_ops", and we call _that_ the "low target" at places (seems its my own fault for introducing that ambiguity...) ... ) So to me that suggests "nat", "native" or "low", in my order of preference. These new target-resume.h, target-wait.h, target-waitstatus.h, target-waitstatus.c files might be looked at as actually something else. This is code defining the interface between GDB core and target_ops, and as such is used by all sort of targets on the GDB side (remote.c, etc.). I'm not sure they should go in the same directory as the *-nat.c, etc. files. GDBserver's "struct target_ops" is both smaller, and different at places from GDB's own "struct target_ops". In a world where we fuse gdb's and gdbserver's target backends, it's not clear to me at this point whether we'll end up with only one "struct target_ops", or whether we'll still end up with two different structures, with parts of GDBserver core implementing GDB's own target_ops, and marshalling things to the lower GDBserver's struct target_ops, while handling others behind GDB core's back. I guess I'm saying, someone should sit, and think this through, and come up with a design/guide of what things look like in the end, before we start moving things around too much. In the mean time, I propose avoiding diverging from Luis' original goal, and continuing what we had been doing, by putting target-resume.h, target-wait.h, target-waitstatus.h, target-waitstatus.c under common/. Further moves can always be done later. WDYT? -- Pedro Alves