From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29033 invoked by alias); 25 Jul 2005 18:06:19 -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 28621 invoked by uid 22791); 25 Jul 2005 18:06:06 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 25 Jul 2005 18:06:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1Dx7L1-0003Cr-AK; Mon, 25 Jul 2005 14:06:03 -0400 Date: Mon, 25 Jul 2005 18:06:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: paul@codesourcery.com, gdb-patches@sources.redhat.com Subject: Re: [csl-am] missing SIGTRAP Message-ID: <20050725180603.GA12217@nevyn.them.org> Mail-Followup-To: Mark Kettenis , paul@codesourcery.com, gdb-patches@sources.redhat.com References: <200504291518.05038.paul@codesourcery.com> <20050725150454.GA6329@nevyn.them.org> <200507251759.j6PHx4M4008405@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507251759.j6PHx4M4008405@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00193.txt.bz2 On Mon, Jul 25, 2005 at 07:59:04PM +0200, Mark Kettenis wrote: > I was going to ignore this patch for mainline, since it indeed isn't > the right way. Then I took a look at the simulators and how much of a > PAIN it's going to be to migrate them off of host signal numbers. > > Does anyone object to the inclusion of this patch? > > The problem here is the fact that the simulator tries to map host > events and simulator events to the same thing isn't it? I'm not too > concerned with the simulators, but I think someone who does care > should really fix this. Meanwhile I don't object to a local hack in > gdb/remote-sim.c. No, I think that the problem is simpler than that. The simulator doesn't care about host events. It's mapping target events to signal numbers; it just picked the SIG* numbers instead of the TARGET_SIGNAL_* numbers. Which are only recently (in the grand scheme of things - about three years ago) available in include/gdb/. > However, I *do* object to the change to gdb/signals/signals.c. This > is supposed to be a host to target mapping of signals. Making it > pretend that the host has SIGTRAP while it doesn't is a truly bad > thing to do. Well then the hack in remote-sim.c will have to be a bit more intrusive... it calls target_signal_to_host and target_signal_from_host on this value. That's doable. -- Daniel Jacobowitz CodeSourcery, LLC