From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3473 invoked by alias); 28 Feb 2002 17:43:57 -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 3367 invoked from network); 28 Feb 2002 17:43:46 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 28 Feb 2002 17:43:46 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16gUal-0002pz-00; Thu, 28 Feb 2002 12:43:43 -0500 Date: Thu, 28 Feb 2002 09:43:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] gdbserver signal handling Message-ID: <20020228124343.A10331@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20020227231216.A6045@nevyn.them.org> <3C7E462C.6050209@cygnus.com> <20020228115501.B8496@nevyn.them.org> <3C7E67F6.4090205@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7E67F6.4090205@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00747.txt.bz2 On Thu, Feb 28, 2002 at 12:25:10PM -0500, Andrew Cagney wrote: > >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. What do you consider "properly", then? For one minor thing, GDB wants the conversion functions to return an `enum target_signal' whereas gdbserver has no need to include "signals.h" in every file and only wants an `int' back to send to the remote client. For another, the important reason in that paragraph was not the include of "defs.h" but the no code sharing. I've gone to great lengths now to see that changes to GDB will not break gdbserver. And these functions have been updated only perhaps once a year for new signals, so the duplication does not convern me overmuch. Since you seem to strongly prefer sharing it, though, I suppose I could do this instead: - create a new directory (``common''?) for files with well-defined interfaces. - Move signals.c in there. Create signals.h in there. - Add that directory to the search paths for both GDB and gdbserver. This would probably mean picking up the big signal to name conversion table in gdbserver, which I wanted to avoid but no one else seemed concerned about. Meanwhile? Just leave signal handling in gdbserver crippled for the upcoming branch? OK, I guess. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer