From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25097 invoked by alias); 30 Jan 2005 19:55:39 -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 25028 invoked from network); 30 Jan 2005 19:55:22 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 30 Jan 2005 19:55:22 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc11) with SMTP id <2005013019551601100dk3t4e>; Sun, 30 Jan 2005 19:55:21 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 30 Jan 2005 19:55:00 -0000 Subject: Re: [gdbserver/patch] Z packet support From: Paul Schlie To: Daniel Jacobowitz CC: Orjan Friberg , Message-ID: In-Reply-To: <20050130173604.GA7745@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-01/txt/msg00308.txt.bz2 > From: Daniel Jacobowitz >> On Sun, Jan 30, 2005 at 10:57:17AM -0500, Paul Schlie wrote: >>> 2. Please re-read the comment; it should not be void *. It is also >>> required that it be harmless for CORE_ADDR to be too large; see >>> MIPS n32 vs n64. >> [ Regarding: And while at it, move CORE_ADDR tweak server.h to wherever >> it likely belongs? (and/or redefine it to void* if more appropriate)? ] >> >> - sorry, it simply seemed implied by your own comment on the subject: >> >> "CORE_ADDR is always a long long in gdbserver, so your sizeof (addr) >> probably doesn't work right for 32-bit targets. I guess sizeof >> (void *) is always right for this, though... at least for the kinds >> of targets gdbserver supports now." >> >> combined with it's own FIXME comment: >> >> /* FIXME: This should probably be autoconf'd for. It's an integer type >> at least the size of a (void *). */ >> typedef long long CORE_ADDR; > > See the second sentence? :-) It has to be an integer type, which void > * is not. CORE_ADDR has to be at least as large as a target address. - fair enough, missed that; so Orjan's use of sizeof(addr), which is a CORE_ADDR, is basically correct; assuming the host platform's long long is long enough as you point out, which seems like a reasonably safe bet? > When talking back to GDB, we should endeavour to use the actual size of > a target address, because sometimes 32-bit GDBs will get annoyed when > they receive 64-bit numbers. > >>> 3. There are nowhere near enough exported functions to justify >>> proliferating headers. >> >> - sorry, guess I always considered "proliferating headers" as required >> a superior alternative to the maintenance problems which proliferating >> redundant declarations otherwise creates. > > I guess I don't understand you. In what way are these declarations > "redundant"? (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) > -- > Daniel Jacobowitz