From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2164 invoked by alias); 29 Apr 2009 19:51:00 -0000 Received: (qmail 2156 invoked by uid 22791); 29 Apr 2009 19:50:59 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 19:50:53 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3TJopp1014427 for ; Wed, 29 Apr 2009 15:50:51 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3TJopBW022557 for ; Wed, 29 Apr 2009 15:50:51 -0400 Received: from localhost.localdomain (vpn-12-136.rdu.redhat.com [10.11.12.136]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3TJoneo025995 for ; Wed, 29 Apr 2009 15:50:50 -0400 Date: Wed, 29 Apr 2009 19:51:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: Mingw GDB build fails for M16C target Message-ID: <20090429125049.054d90b8@redhat.com> In-Reply-To: <20090429023511.GA2873@caradoc.them.org> References: <82C3BC9106BCE149B63464D79D0A22FD0A68110C@sohm.kpit.com> <20090428155724.1797d332@redhat.com> <20090429023511.GA2873@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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/msg00791.txt.bz2 On Tue, 28 Apr 2009 22:35:11 -0400 Daniel Jacobowitz wrote: > On Tue, Apr 28, 2009 at 03:57:24PM -0700, Kevin Buettner wrote: > > Jim, > > > > It appears to me that comment, "Oddly, the gdb/sim interface uses host > > signal numbers...", isn't true. My patch deletes this comment in > > addition to using TARGET_SIGNAL_foo instead of SIGfoo. If you look at > > remote-sim.c, you'll see that `enum target_signal' (which defines the > > various TARGET_SIGNAL_foo constants) is used throughout the file. > > 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. > 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. Kevin