From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28486 invoked by alias); 28 Feb 2002 20:30:32 -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 28405 invoked from network); 28 Feb 2002 20:30:25 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 28 Feb 2002 20:30:25 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16gXC3-0004J9-00; Thu, 28 Feb 2002 15:30:23 -0500 Date: Thu, 28 Feb 2002 12:30:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] gdbserver signal handling Message-ID: <20020228153023.A16149@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> <20020228124343.A10331@nevyn.them.org> <3C7E8527.4070005@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7E8527.4070005@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00750.txt.bz2 On Thu, Feb 28, 2002 at 02:29:43PM -0500, Andrew Cagney wrote: > >>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. > > I don't understand. Presumably any file that needs to use one of the > signal conversion routines would include "signals.h" and get both the > enum and the function signature. Beyond that, I don't think anyone is > going to notice if the code assigning the result to an int. (I'm still > working on a -Wassign-enum flag for GCC :-^). I'd rather have left the enum as opaque in gdbserver; nothing cares. I guess it doesn't matter at all. > >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. > > Not to long ago I suggested splitting up utils.c into smaller more > independant files and a directory (gdb/utils/). > > We could do similar to signals.c. We could even split the string > functions off from the conversion functions so that gdbserver didn't get > bloated by them. > > However, not in the next three days :-) OK, sounds good to me. I'll discuss exactly where to split the files after we branch. > >Meanwhile? Just leave signal handling in gdbserver crippled for the > >upcoming branch? OK, I guess. > > Yes. It isn't as bad as it sounds though. The problem has always been > there so we're not exactly fixing a regression. Besides, the next > release is only 22 weeks away. My motivation to finish this before release was that this was the only remaining set of tests which gdbserver should have been able to pass and could not after my rewrite; it'll be built on a lot more platforms now, and probably used more. It didn't pass particularly many of them beforehand. This isn't terribly important to me, since I'm only responsible for two distributions of GDB and both of them have patch application mechanisms (:-)), but I suspect we'll see it reported pretty frequently over the next 22 weeks. I agree that the patch isn't ideal; but if a proper fix goes in the mainline can we put this on the branch? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer