From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32350 invoked by alias); 30 Jan 2005 20:38:48 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32333 invoked from network); 30 Jan 2005 20:38:44 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 30 Jan 2005 20:38:44 -0000 Received: from drow by nevyn.them.org with local (Exim 4.43 #1 (Debian)) id 1CvLq3-0001zf-JL; Sun, 30 Jan 2005 15:38:31 -0500 Date: Sun, 30 Jan 2005 20:38:00 -0000 From: Daniel Jacobowitz To: Paul Schlie Cc: Orjan Friberg , gdb-patches@sources.redhat.com Subject: Re: [gdbserver/patch] Z packet support Message-ID: <20050130203830.GA7506@nevyn.them.org> Mail-Followup-To: Paul Schlie , Orjan Friberg , gdb-patches@sources.redhat.com References: <20050130173604.GA7745@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2005-01/txt/msg00309.txt.bz2 On Sun, Jan 30, 2005 at 02:55:15PM -0500, Paul Schlie wrote: > (with respect to "redundant", you're likely correct in questioning my use > of that word, as I had mistakenly assumed that many of the declarations > in server.h, also logically appeared in their corresponding source file > headers; as opposed to being disassociated with them.) > > where for for example in server.h: > > /* Functions from remote-utils.c */ > > int putpkt (char *buf); > ... > > where putpkt implementations matching that prototype are defined in both > remote.c and remote-utils.c, but prototyped in remote.h, and server.h; > where it would have seemed simpler and more consistent to declare public > prototypes in the corresponding header files associated with a function's > implementation, which may then be included by source files as required, > thereby establishing a clear dependency, which would seem to help make > file dependency generation, etc. not to mention general clarity affecting > maintainability of the of the sources. (as just an opinion) You seem to be somewhat confused about one thing, which explains your comment better. GDB and gdbserver are completely independent programs. There are a few bits of shared code, e.g. the signals/ directory, but they are compiled separately for each. "remote.h" and "remote.c" are part of GDB. "server.h" and "remote-utils.c" are is part of gdbserver. Therefore, there is no redundancy; the overlap in function names is basically coincidence. server.h provides prototypes for most of the target-independent files in gdbserver. -- Daniel Jacobowitz