From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8725 invoked by alias); 19 Sep 2006 01:20:16 -0000 Received: (qmail 8716 invoked by uid 22791); 19 Sep 2006 01:20:15 -0000 X-Spam-Check-By: sourceware.org Received: from omta03sl.mx.bigpond.com (HELO omta03sl.mx.bigpond.com) (144.140.92.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Sep 2006 01:20:12 +0000 Received: from kiwi.ods.com.au ([60.227.162.172]) by omta03sl.mx.bigpond.com with ESMTP id <20060919012009.XSXE8785.omta03sl.mx.bigpond.com@kiwi.ods.com.au>; Tue, 19 Sep 2006 01:20:09 +0000 Received: from [172.16.100.194] (lapdog.ods.com.au [172.16.100.194]) by kiwi.ods.com.au (8.12.8/8.12.8) with ESMTP id k8J1K6OG006928; Tue, 19 Sep 2006 11:20:08 +1000 Message-ID: <450F45CC.4060503@rtems.org> Date: Tue, 19 Sep 2006 01:20:00 -0000 From: Chris Johns User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: gdb-patches@sources.redhat.com CC: Eli Zaretskii Subject: Re: H8300 simulator on MinGW fails to compile. 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> <20060916035255.GA7425@nevyn.them.org> In-Reply-To: <20060916035255.GA7425@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00103.txt.bz2 Daniel Jacobowitz wrote: > > 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. > I now understand the source of signals when run as a stand alone program. > 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. > This is how I see the flow. I think it is simplest to try and get to just SIM_* and TARGET_SIGNAL_* and no host signal numbers in the simulators. > 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? Yeap will do. > >> 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. > I am not sure I understand what you mean by running the gcc testsuite. I will also chat to Joel Sherrill as he has put the H8300 into RTEMS and see what RTEMS tests we can run. Thanks. Regards Chris