From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30338 invoked by alias); 7 Mar 2002 15:59:50 -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 30214 invoked from network); 7 Mar 2002 15:59:47 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.135.44) by sources.redhat.com with SMTP; 7 Mar 2002 15:59:47 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 932B33E73; Thu, 7 Mar 2002 10:59:39 -0500 (EST) Message-ID: <3C878E6B.9000704@cygnus.com> Date: Thu, 07 Mar 2002 07:59:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb@sources.redhat.com Cc: Elena Zannoni , Eli Zaretskii , Daniel Jacobowitz Subject: Re: New directory src/gdb/misc? References: <20020307003134.B20240@nevyn.them.org> <15495.32556.289737.444380@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-03/txt/msg00045.txt.bz2 > Eli Zaretskii writes: > > > On Thu, 7 Mar 2002, Daniel Jacobowitz wrote: > > > > > 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. > > > Either `common' or maybe `lib' (or `gdblib'). I agree that `misc' is not > > such a good idea. > > how about 'generic' (stolen from gdbtk) or 'shared' or 'general' ? > > Elena `Generic' could be interpreted to mean everything except the architecture stuff. (I think I regret raising this one :-) Starting again ... Perhaphs I'm trying to simultaneously squeese a square and triangular peg through a round hole - ``nat'' stuff related to host=target. gdbserver and gdb have the potential to share this. Signal mapping and ptrace() are probably the only things that live here. Shared libraries, threads, core files, ... are all no longer ``native''. - ``utils'' for just getting gdb to build. safe_strerror(), xfree(), ... This does open up the more general question of how to restructure GDB. Hopefully that discussion can be side stepped and just persue this to the point of being fairly sure we're not heading in a completly wrong direction. Is the right direction to split things across ``functional'' (utils, nat, isa/abi, ..) lines rather than ``usage'' (common to gdb/gdbserver, commont to gdb/sim, ...) lines? A functional split would result in gdbserver cherry picking from random directories the bits it wants from core gdb. Andrew