From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27697 invoked by alias); 7 Mar 2002 05:31:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27637 invoked from network); 7 Mar 2002 05:31:33 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 7 Mar 2002 05:31:33 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16iqV4-0005Id-00 for ; Thu, 07 Mar 2002 00:31:34 -0500 Date: Wed, 06 Mar 2002 21:31:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: New directory src/gdb/misc? Message-ID: <20020307003134.B20240@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <3C86D0FA.6010801@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C86D0FA.6010801@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00034.txt.bz2 On Wed, Mar 06, 2002 at 09:31:22PM -0500, Andrew Cagney wrote: > Hello, > > Some may have noticed DanielJ's and my discussion about better sharing > of the signals.c code between GDB and GDBSERVER. > > I'd previously posted a suggestion that gdb/utils.c be broken down into > smaller parts and moved to a new directory gdb/utils/. utils.c is > running into system include header problems, that should be easier to > handle if there are a number of smaller more independant files. > > In addition to this GDBSERVER and GDB contain a number of common chunks > of code related to signal handling and conversion. The proposal is to > break signals.c down into smaller files in the directory gdb/common/. > > Having had a bit of time to think this over, I suspect a gdb/utils/ > directory is wrongly named - utils makes me think of utility programs. > > This leaves ``gdb/common'' and, (new suggestion) gdb/misc/ as possible > directory names. 'misc' doesn't convey any information. It's like calling something 'new' in its documentation - not useful for very long. I'd vote for common. Ideally, there would be other files as GDB became gradually more modular. THat's something to talk about later though. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer