From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: Mingw GDB build fails for M16C target
Date: Wed, 29 Apr 2009 19:51:00 -0000 [thread overview]
Message-ID: <20090429125049.054d90b8@redhat.com> (raw)
In-Reply-To: <20090429023511.GA2873@caradoc.them.org>
On Tue, 28 Apr 2009 22:35:11 -0400
Daniel Jacobowitz <drow@false.org> 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
next prev parent reply other threads:[~2009-04-29 19:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <82C3BC9106BCE149B63464D79D0A22FD0A68110C@sohm.kpit.com>
2009-04-28 22:57 ` Kevin Buettner
2009-04-29 2:35 ` Daniel Jacobowitz
2009-04-29 19:51 ` Kevin Buettner [this message]
2009-04-29 20:01 ` Daniel Jacobowitz
2009-04-29 20:27 ` Kevin Buettner
2009-04-29 20:33 ` Daniel Jacobowitz
2009-05-08 22:57 ` Kevin Buettner
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=20090429125049.054d90b8@redhat.com \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
/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