From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25483 invoked by alias); 28 Feb 2002 17:25:18 -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 25404 invoked from network); 28 Feb 2002 17:25:13 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 28 Feb 2002 17:25:13 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4CCA93D79; Thu, 28 Feb 2002 12:25:10 -0500 (EST) Message-ID: <3C7E67F6.4090205@cygnus.com> Date: Thu, 28 Feb 2002 09:25: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: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] gdbserver signal handling References: <20020227231216.A6045@nevyn.them.org> <3C7E462C.6050209@cygnus.com> <20020228115501.B8496@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00746.txt.bz2 > Er, why did you create src/gdb/signals.c? > > > The reason to create src/gdb/signals.c has nothing to do with > gdbserver; it has to do with: > - the cleanup I never got to of removing from target.c, > since is a host header but used for target information. > > - the eventual moving of signals.c to be in NATDEPFILES. > > I don't want to move it to gdbserver, because I've finally reached no > code sharing. And because of something you said once, which is now > true: > >> I think, in terms of better splitting up gdbserver and gdb it is pretty >> much a requirement. I can but dream of the day when GDBSERVER stops >> including defs.h :-) > > > > That's why I wanted to do it the above way. I suspect there is a difference between not including defs.h and unnecessarily duplicating common code. My memory was that the signal enums were to be moved to their own header file (so things like gdbserver could include them). This gdb/gdbserver/signals.c looks largely like a copy of big chunks of gdb/signals.c and other similar code. I don't know that gdb developers want to take on responsability for maintaining such duplication. Again, I think this can be cleaned up properly, but after the 5.2 branch goes through. enjoy, Andrew