From: Chris Johns <chrisj@rtems.org>
To: gdb-patches@sources.redhat.com
Cc: Eli Zaretskii <eliz@gnu.org>
Subject: Re: H8300 simulator on MinGW fails to compile.
Date: Tue, 19 Sep 2006 01:20:00 -0000 [thread overview]
Message-ID: <450F45CC.4060503@rtems.org> (raw)
In-Reply-To: <20060916035255.GA7425@nevyn.them.org>
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
prev parent reply other threads:[~2006-09-19 1:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-13 12:33 Chris Johns
2006-09-13 16:55 ` Eli Zaretskii
2006-09-13 20:10 ` Chris Johns
2006-09-13 20:30 ` Daniel Jacobowitz
2006-09-14 1:22 ` Chris Johns
2006-09-14 3:05 ` Daniel Jacobowitz
2006-09-14 23:43 ` Chris Johns
2006-09-16 3:53 ` Daniel Jacobowitz
2006-09-19 1:20 ` Chris Johns [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=450F45CC.4060503@rtems.org \
--to=chrisj@rtems.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox