From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31357 invoked by alias); 24 Mar 2002 21:34:32 -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 31350 invoked from network); 24 Mar 2002 21:34:30 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 24 Mar 2002 21:34:30 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16pFdM-0001do-00 for ; Sun, 24 Mar 2002 16:34:36 -0500 Date: Sun, 24 Mar 2002 13:34:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Where to put gdb/gdbserver-shared code? Message-ID: <20020324163436.A6026@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i X-SW-Source: 2002-03/txt/msg00219.txt.bz2 There was some discussion a month or so about sharing signals.c between gdb and gdbserver. This comes up fairly often; we never quite decided how to treat it. Kevin seemed to be of the school that says there should be no code sharing, and Andrew leant the other way (as I remember - apologies for misrepresentation!). I dislike it in general, and having just eliminated every last bit of it I'm reluctant to introduce more, but signals.c is a good candidate if ever there was one. Ignoring that for the moment though, if we are going to share it, where should we keep it? We could keep it in a directory clearly describing its role ("native" or "utils") or clearly describing its status as shared ("common"). I don't want to leave it where it is if it's going to be shared. Since I don't see the transition to lots and lots of common, shareable code with well-defined boundaries in our near future, I lean towards "common". Longer term, I'd prefer something like "native/utils/" and a well-described allowable interface for code in that directory; I don't know how practical that is yet. Thoughts? Preferences? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer