From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4069 invoked by alias); 31 Jul 2013 19:03:45 -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 4057 invoked by uid 89); 31 Jul 2013 19:03:44 -0000 X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_40,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; Wed, 31 Jul 2013 19:03:44 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6VJ3YXS004803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 15:03:34 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6VJ3WBo005291; Wed, 31 Jul 2013 15:03:33 -0400 Message-ID: <51F95F84.3090709@redhat.com> Date: Wed, 31 Jul 2013 19:03: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: "'gdb-patches@sourceware.org'" , Tom Tromey Subject: Re: [PATCH] Share more common target structures between gdb and gdbserver References: <51E595A0.6090500@codesourcery.com> <51F7FC4E.3050604@redhat.com> <51F95AD5.9050200@codesourcery.com> In-Reply-To: <51F95AD5.9050200@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00840.txt.bz2 On 07/31/2013 07:43 PM, Luis Machado wrote: > On 07/30/2013 02:47 PM, Pedro Alves wrote: >> On 07/16/2013 07:49 PM, Luis Machado wrote: >>> Hi, >>> >>> While doing some research about the remote fork following feature, i >>> noticed there was some duplication of target data structures for GDB and >>> gdbserver. >>> >>> This patch moves the shareable code/data structures to >>> common/target-common.* and makes both GDB and gdbserver target files >>> reference the header common/target-common.h. >>> >>> Makefiles and other files have been adjusted accordingly. >> >> I'd very much prefer avoiding "common" in file names, instead >> naming the files for what they contain, not for the fact that they're >> "common" to two programs (gdb, gdbserver) presently. I think of it >> this way -- when we finally end up with only one backend (or one >> backend using a foo-common.c file), I'd rather avoid >> renaming these files to something else, because they're no longer >> "common". Or, yet IOW, think of common/ as a library. Can you >> imagine if all libraries in a distro named their implementation >> files "foo-common.c" ? Because that's what should happen given >> they're used by lots of programs, right? :-) The direction I prefer >> is, when moving things to common/ we take the opportunity to split them >> into smaller, more atomic, leaner units. E.g., that's how we ended up >> with ptid.h/ptid.c, instead of inferior-common.h (or some such). > > It makes sense to me, though i think we may have to think about creating > directories of subsystems instead of laying files the old way in a flat > directory structure. Agreed. My bare-minimal initial idea was to end up with the target backend stuff in its own dir: gdb/common/ (utils.c, etc., host independent bits.) gdb/target/ (the backends) (Given git is smart enough to understand moves automatically, I no longer worry about losing cvs history when doing file moves these days.) > We still have a handful of files in common, so maybe it is a good > starting point for that. > >> If the file is just a dumping ground of misc things, then let's at >> least call it that. Say, target-misc.h or target-defs.h. > > I'll declare them target-defs.h and target-misc.h/target-misc.c. How > does that sound? No real objection, but is target-waitstatus.h/target-waitstatus.c too fine-grained? >> (I have absolutely nothing again John, but this shows how >> "contributed by"/"written by" lines are a disservice to future >> hackers, IMO. Lot's of code here that others wrote.) >> > > Not wanting to offend John, but should i just remove this line in the > upcoming patch? IMO, yes. This new file holds bits that are newer than the original target vector. >>> +/* Interface between the debugger and target environments, including files >>> + and processes, shared between GDB and gdbserver. The leading comment should be adjusted as well. This file does not really hold the target interface definition. -- Pedro Alves