From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8468 invoked by alias); 16 Sep 2006 03:53:01 -0000 Received: (qmail 8457 invoked by uid 22791); 16 Sep 2006 03:53:00 -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; Sat, 16 Sep 2006 03:52:58 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GOREd-0001yq-Sg; Fri, 15 Sep 2006 23:52:56 -0400 Date: Sat, 16 Sep 2006 03:53:00 -0000 From: Daniel Jacobowitz To: Chris Johns Cc: gdb-patches@sources.redhat.com, Eli Zaretskii Subject: Re: H8300 simulator on MinGW fails to compile. Message-ID: <20060916035255.GA7425@nevyn.them.org> Mail-Followup-To: Chris Johns , gdb-patches@sources.redhat.com, Eli Zaretskii References: <4507FA7A.70504@rtems.org> <450865A0.7070604@rtems.org> <20060913203009.GA21009@nevyn.them.org> <4508AEC7.4040803@rtems.org> <20060914030529.GA31175@nevyn.them.org> <4509E901.6080600@rtems.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4509E901.6080600@rtems.org> User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2006-09/txt/msg00080.txt.bz2 On Fri, Sep 15, 2006 at 09:42:57AM +1000, Chris Johns wrote: > Daniel Jacobowitz wrote: > > > >I'm not entirely sure any more; it's been ages since I looked at these. > >I think the SIM_SIG* constants may be older than the TARGET_SIGNAL_* > >constants; I don't think we need both... but I really don't know. The > >problem is that a given int variable could hold any of the three right > >now. > > > > I am confused about the source of the host signals. The nrun.c file has > code to handle the host signals. Are they coming from the gdb UI or > something similar ? There's at least two different things at issue here. nrun.c, I believe, does not get linked in when the simulator is used from GDB. Instead, it's only used for the 'foo-elf-run' binaries. As such, it receives actual host signals (specifically SIGINT). So that's undoubtedly a host signal number. But then that queues up SIM_SIGINT inside the simulator. What's interesting is to trace a particular use of a host signal number through the various files, and figure out where it's set and used. I can generally do them one at a time. For instance, the h8300 use of SIGBUS: sim_engine_set_run_state (sd, sim_stopped, SIGBUS); One call site for sim_engine_set_run_state passes SIM_SIGTRAP, another passes pending_sigrc, but both are inside #if 0. Another passes 0. Everything else uses a host signal number, and comes from the h8300 sim. The signal number gets stored in engine->sigrc. There's two ways to get it out again: sim_stop_reason leaves it as is if sim_exited and treats it as a SIM_* signal if sim_stopped or sim_signalled, and sim_engine_get_run_state just returns it. The other way to set ->sigrc is sim_engine_halt. And pretty much all call sites use SIM_* constants for that, as far as I checked. So what all that boils down to is, I think the h8300 sim is simply wrong. The use of SIGINT for signal() is fine, but all the others should probably be changed. Then you won't need the definitions any more. Want to give it a try? > What is simplest way to run 'make check' on the simulator ? Some simulators have a testsuite, others don't; h8300 appears not to. You can always stress it by using it to run other things, like the GCC testsuite. -- Daniel Jacobowitz CodeSourcery