From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17120 invoked by alias); 29 Apr 2009 20:01:38 -0000 Received: (qmail 16411 invoked by uid 22791); 29 Apr 2009 20:01:34 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 20:01:29 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 8B27210738 for ; Wed, 29 Apr 2009 20:01:26 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 358FB10554 for ; Wed, 29 Apr 2009 20:01:26 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LzFy8-0000Ww-DZ for gdb-patches@sourceware.org; Wed, 29 Apr 2009 16:01:24 -0400 Date: Wed, 29 Apr 2009 20:01:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: Mingw GDB build fails for M16C target Message-ID: <20090429200124.GA961@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <82C3BC9106BCE149B63464D79D0A22FD0A68110C@sohm.kpit.com> <20090428155724.1797d332@redhat.com> <20090429023511.GA2873@caradoc.them.org> <20090429125049.054d90b8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090429125049.054d90b8@redhat.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00792.txt.bz2 On Wed, Apr 29, 2009 at 12:50:49PM -0700, Kevin Buettner wrote: > > Shouldn't this be the same as common/sim-signal.c? sim_signal_to_host > > uses native numbers and sim_signal_to_target uses GDB protocol > > numbers. > > It's not clear to me what you're asking about. > > If you're asking why m32c/gdb-if.c doesn't use common/sim-signal.c, > that's because the m32c sim doesn't use the infrastructure in common/ > at all. > > If you're asking why I don't simply copy sim_signal_to_target for > use in m32c/gdb-if.c, that's because the m32c sim doesn't use the > SIM_SIGfoo constants that common/sim-signal.c uses. It does bother me > though that m32c_signal_to_target() uses hardcoded constants like 4, > 5, 10, 11, etc. I suspect it was done this way because including the > correct newlib header file (without conflict with certain system > headers) was difficult. That's just a guess though. I was actually asking about sim_signal_to_host, since this was m32c_signal_to_host. The sim_ version uses SIGILL, SIGTRAP, etc. > > Then again, I'm totally baffled by this bit of the sim. It looks like > > sim_stop_reason returns a target signal and the callers check it > > against a host signal??? > > I looked at that yesterday prior to posting my patch. I thought I > understood what was going on, but now that I look at it closer, I > too am baffled. I noticed yesterday that signal() is being called to > handle SIGINT. My thought at the time was that the handler was > somehow manipulating the sim's state so that it would return the sim > specific code for the signal. But that's not what's happening. The > handler simply checks to make sure that it (the sim) is not stopped; > if not, it prints a message, and then exits. So it seems to me that > sim_signal_to_host() and that check that you mention are completely > unnecessary. Yes... I don't think any of the conversion routines that use host numbers should be there. I'm not feeling ambitious enough to remove them from all sims, but perhaps you can get just m32c? -- Daniel Jacobowitz CodeSourcery