From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10464 invoked by alias); 30 Jan 2005 17:36:26 -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 10341 invoked from network); 30 Jan 2005 17:36:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 30 Jan 2005 17:36:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.43 #1 (Debian)) id 1CvIzU-00021u-6g; Sun, 30 Jan 2005 12:36:04 -0500 Date: Sun, 30 Jan 2005 17:36: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: <20050130173604.GA7745@nevyn.them.org> Mail-Followup-To: Paul Schlie , Orjan Friberg , gdb-patches@sources.redhat.com References: <20050130153812.GA5311@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/msg00307.txt.bz2 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. 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"? -- Daniel Jacobowitz