From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28235 invoked by alias); 30 Jan 2005 15:38:31 -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 28201 invoked from network); 30 Jan 2005 15:38:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 30 Jan 2005 15:38:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.43 #1 (Debian)) id 1CvH9R-0001QC-5n; Sun, 30 Jan 2005 10:38:13 -0500 Date: Sun, 30 Jan 2005 15: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: <20050130153812.GA5311@nevyn.them.org> Mail-Followup-To: Paul Schlie , Orjan Friberg , gdb-patches@sources.redhat.com References: 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/msg00305.txt.bz2 On Sun, Jan 30, 2005 at 10:32:30AM -0500, Paul Schlie wrote: > In the spirit of the present structure of the file, might it make > more sense to actually add decode_Z_packet (... ) to remote-utils.c, > along with possibly the thread stuff, and use it correspondingly in > server.c, before it gets out of hand? > > And while at it, move CORE_ADDR tweak server.h to wherever it likely > belongs? (and/or redefine it to void* if more appropriate)? > > /* 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; > > > And remove redundant declarations from server.h, and include required > respective headers in server.c > > /* Functions from remote-utils.c */ > void decode_M_packet (char *from, CORE_ADDR * mem_addr_ptr, > unsigned int *len_ptr, char *to); > ... > /* Functions from ``signals.c''. */ > ... > > ??? (although I know it's easier said than done?) 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. 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. 3. There are nowhere near enough exported functions to justify proliferating headers. -- Daniel Jacobowitz