From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13376 invoked by alias); 5 Aug 2013 10:44:03 -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 13357 invoked by uid 89); 5 Aug 2013 10:44:03 -0000 X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,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; Mon, 05 Aug 2013 10:44:02 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r75AhrrQ002248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Aug 2013 06:43:53 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r75Ahox1002786; Mon, 5 Aug 2013 06:43:51 -0400 Message-ID: <51FF81E6.7050006@redhat.com> Date: Mon, 05 Aug 2013 10:44: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: Tom Tromey CC: lgustavo@codesourcery.com, "'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> <51FB7BFB.90100@redhat.com> <87txj7byz7.fsf@fleche.redhat.com> In-Reply-To: <87txj7byz7.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00133.txt.bz2 On 08/02/2013 09:48 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> "target" is an overloaded word in GDB-speak. My idea for this new > Pedro> directory, would be for it to hold the native target backend bits. > Pedro> But "target" could also suggest that corelow.c, file.c, remote.c, etc. > Pedro> should be put in this directory, while I don't think they should. > > I've been thinking about this a bit since the discussion yesterday. > > I think I'm generally in favor of using the names Luis already has. > > The basic reason I have is that I think that, by and large, gdb's module > boundaries make sense. I may quibble with some exact lines that have > been drawn (and certainly I dislike the insides of some modules), but by > and large the modules, at least as I understand the breakdown, have > proven resilient. > > I agree that "target" is not the best possible name de novo. However, > it is the nature of language to overload words with meanings -- the > norm, not the exception -- and furthermore "target" is the name > historically chosen inside gdb to represent the connection between the > core (+ CLI) and the back end. I've read your email several times over, and I sense that we're talking past each other. Myself, I'm used to the use of "target", in "struct target_ops" & friends, and I have no desire to push into a change here. "back end" is also a little vague, in that the gdbarch bits could also be seen as a backend. When trying to think of a more precise term, I end up thinking of "target" representing the connection between the core and a system's debug API (though that has it's own shortfalls too). So "target" being vague is good. :-) > You had a few specific issues, which I've quoted & will address below. > > Pedro> Sounds like a better name for this native target backend directory > Pedro> should be invented. GDB uses *-nat.c naming for most of > Pedro> these files, while GDBserver uses *-low.c. > > I think it's fine to use "nat" in the same way that gdb does now. > > Looking at the current patch, though, I don't see anything "nat" in > there. Sure. But this thread is coming as preparatory work for the ptrace-sharing patch, and the gdbserver fork support work, and if you look at http://sourceware.org/ml/gdb-patches/2013-07/msg00840.html you'll see that the original "target/" directory was thrown around as place for holding the native backends. If we don't use "target/" for the native backends, then, yes, a "target/" directory for target_ops things would make better sense. (I'm not excluding a "target/nat/linux/" subdirectory scheme, though, to me, that's less a concern than 'target/ for all' vs 'target/ + nat/'.) > The ptrace options discovery bits could go there, but that > wasn't addressed in this thread IIRC. So what I'm trying to point out, is that the new files in the patch in these threads are not really "native backend" files, so they best not go in the "native backend" files directory. IOW, after this, and http://sourceware.org/ml/gdb-patches/2013-07/msg00788.html and continuing that direction, I don't think we would want to end up with: target/resume.h target/waitstatus.[c|h] target/wait.h target/i386-nat.c target/linux-nat.c target/linux-ptrace.c target/linux-waitpid.c etc. > > Pedro> These new target-resume.h, target-wait.h, target-waitstatus.h, > Pedro> target-waitstatus.c files might be looked at as actually something > Pedro> else. This is code defining the interface between GDB core and > Pedro> target_ops, and as such is used by all sort of targets on the > Pedro> GDB side (remote.c, etc.). I'm not sure they should go in the same > Pedro> directory as the *-nat.c, etc. files. > > These seem like classic "target" bits to me. Yep. So, if we move the classic "target" bits to a "target/" module directory, and put the native bits in their own dir, we have: target/resume.h target/waitstatus.[c|h] target/wait.h nat/i386-nat.c nat/linux-nat.c nat/linux-ptrace.c nat/linux-waitpid.c etc. Is this what you're thinking of? _This_, I'm fine with. No mix of native bits with generic "target" bits, which was my main worry. It's actually very similar to something else I suggested on IRC, but forgot to put in email form: "IMO, the interfaces themselves would be in an include dir. e.g., gdb/include/target-waitstatus.h or some such, and then we'd have gdb/nat/linux-nat.c, etc." What else goes in "target/" ? remote.c, corelow.c, etc.? Do we move things into subdirectories beneath it too, for better submodule partitioning? I didn't want to suggest starting a mass move, that's easy to overdo. (That was the point at which I suggested that someone thinks this through, and comes up with an initial design/guide of what things will look like in the end, so that we can then discuss and hash it out.) -- Pedro Alves