From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3062 invoked by alias); 30 Jan 2005 15:57:37 -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 3028 invoked from network); 30 Jan 2005 15:57:30 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 30 Jan 2005 15:57:30 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc13) with SMTP id <2005013015571901600igcq5e>; Sun, 30 Jan 2005 15:57:29 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 30 Jan 2005 15:57:00 -0000 Subject: Re: [gdbserver/patch] Z packet support From: Paul Schlie To: Daniel Jacobowitz CC: Orjan Friberg , Message-ID: In-Reply-To: <20050130153812.GA5311@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-01/txt/msg00306.txt.bz2 > From: Daniel Jacobowitz > If you want to make cosmetic structural changes to gdbserver, and > can show that they actually have benefit, then feel free to file a > copyright assignment and submit patches yourself. > > As it happens: > 1. I don't care either way. - understood. > 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; > 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. > -- > Daniel Jacobowitz