From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7143 invoked by alias); 25 Nov 2005 18:25:20 -0000 Received: (qmail 7119 invoked by uid 22791); 25 Nov 2005 18:25:18 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 25 Nov 2005 18:25:17 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EfiG2-0001Gp-36; Fri, 25 Nov 2005 13:25:14 -0500 Date: Fri, 25 Nov 2005 19:11:00 -0000 From: Daniel Jacobowitz To: Mark Mitchell Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: Use target values for signals in simulator Message-ID: <20051125182514.GG736@nevyn.them.org> Mail-Followup-To: Mark Mitchell , gdb-patches@sources.redhat.com References: <20051123185806.29594.qmail@mail.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051123185806.29594.qmail@mail.codesourcery.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00465.txt.bz2 On Wed, Nov 23, 2005 at 06:58:06PM -0000, mitchell@mail.codesourcery.com wrote: > The principal risk with this patch is that I may have failed to > translate from one of the various simulator's internal representation > of a signal to the appropriate TARGET_SIGNAL_ value. However, because > TARGET_SIGNAL_* uses the conventional UNIX values for signals to the > extent there are conventions (like, TARGET_SIGNAL_SEGV is 11 and > TARGET_SIGNAL_TRAP is 5) it's unlikely that any places I missed will > actually matter. > > In other words, the simulators were already translating to the host > signal numbers, which, in practice, are very likely to match up with > TARGET_SIGNAL_* -- especially since most of the simulators generate a > pretty limited set of signals. So, if I missed a spot, it's very > likely that the values are correct anyhow. Therefore, I think this > patch is pretty safe. You missed sim/ppc/psim.c:cntrl_c_simulation. Of course there's also psim_max_iterations_exceeded, which uses signal -1... let's just ignore that for the moment... Other than that, I think it plausibly likely that you got everything. Does anyone object to this change? This has been a long-standing wart. -- Daniel Jacobowitz CodeSourcery, LLC