From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24224 invoked by alias); 28 Feb 2002 16:55:08 -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 24039 invoked from network); 28 Feb 2002 16:55:03 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 28 Feb 2002 16:55:03 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16gTpd-0002L6-00; Thu, 28 Feb 2002 11:55:01 -0500 Date: Thu, 28 Feb 2002 08:55:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] gdbserver signal handling Message-ID: <20020228115501.B8496@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20020227231216.A6045@nevyn.them.org> <3C7E462C.6050209@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7E462C.6050209@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00743.txt.bz2 On Thu, Feb 28, 2002 at 10:01:00AM -0500, Andrew Cagney wrote: > >2002-02-27 Daniel Jacobowitz > > > >* gdbserver/server.c (main): Call target_signal_to_host_p > > and target_signal_to_host on signals received from the remote. > > * gdbserver/remote-utils.c (prepare_resume_reply): Call > > target_signal_from_host on signals sent to the remote. > > * gdbserver/signals.c: New file. > > * gdbserver/server.h: Add prototypes. > > * gdbserver/Makefile.in: Add signals.o. > > > > > > 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer