From: Pedro Alves <palves@redhat.com>
To: Michael Eager <eager@eagerm.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: MIPS Linux signals
Date: Mon, 21 May 2012 17:37:00 -0000 [thread overview]
Message-ID: <4FBA7D30.50500@redhat.com> (raw)
In-Reply-To: <4FBA5651.4070909@eagerm.com>
On 05/21/2012 03:50 PM, Michael Eager wrote:
> On 05/21/2012 04:03 AM, Pedro Alves wrote:
>> On 05/20/2012 03:02 AM, Michael Eager wrote:
>
>>> 4 -- Do the multiple layers of wrappers around target_
>>> signal_{to,from}_host in signals.c serve any purpose?
>>
>> Can you be more specific? What multiple layers?
>
> target_signal_to_host() is a wrapper around do_target_signal_to_host().
>
> target_signal_to_host_p() is a wrapper around do_target_signal_to_host().
Yes, do_target_signal_to_host is a helper for both target_signal_to_host and
target_signal_to_host_p.
> This appears to be only used in gdbserver, where, on MIPS, it will
> return the wrong result.
Why will it return the wrong result on MIPS/gdbserver? The common/signals.c
copy built into gdbserver will naturally be built with a MIPS headers, and
should pick up the correct signal defines (SIGINT, etc.).
> Incidentally, gdbserver on MIPS calls
> the X86 target_signal_to_host() to translate signals. This seems
> confused.
Now I'm confused. What do you mean that MIPS gdbserver calls the
X86 target_signal_to_host ? There's only one target_signal_to_host
function AFAICS.
> If gdb is translating internal signal numbers to the
> target signal numbers, then this seems to be a second translation.
gdbserver internally translates Linux signal numbers to the host
independent internal signal numbers. We call the latter "target signals",
like we call every method that goes through the "target abstraction"
(target_ops vector) in gdb target_something. The native signals that
are host dependent (host in the same sense as build vs host vs target
on autoconf), we call them host signals.
On the "wire", RSP packets should contain only the abstracted, internal,
target signal numbers. So code on gdbserver that talks to ptrace
will need to convert the (native) host signal numbers to target signals
when pushing events to gdbserver common code, and ultimately to GDB.
AFAIK, there's no such second internal signal numbers to target
signal numbers translation in GDB. The remote target already works with
GDB's own internal signal numbers.
> default_target_signal_to_host() is a wrapper around target_signal_to_host().
>
> default_target_signal_from_host() is a wrapper around target_signal_from_host().
Right. gdbarch_target_signal_from_host was invented long after target_signal_from_host
already existed to solve the similar case you ran into. That is, of when
cross debugging core files. In that case there's no gdbserver involved to do the
host -> gdb/internal signal conversion for us, so GDB needs to do it, according to
the core's gdbarch. If there's no such gdbarch callback installed, then we fallback
to the host's default conversion, which with work when debugging native core files.
So you do have the right fix, but the reason why nobody has tripped on this before is
that this only affects cross core debugging, not live gdbserver debugging.
--
Pedro Alves
next prev parent reply other threads:[~2012-05-21 17:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-20 2:03 Michael Eager
2012-05-21 11:04 ` Pedro Alves
2012-05-21 14:51 ` Michael Eager
2012-05-21 17:37 ` Pedro Alves [this message]
2012-05-21 18:06 ` Michael Eager
2012-05-21 18:19 ` Maciej W. Rozycki
[not found] ` <alpine.DEB.1.10.1205211232260.11227@tp.orcam.me.uk>
2012-05-21 18:21 ` Michael Eager
2012-05-21 22:34 ` Maciej W. Rozycki
2012-05-22 9:38 ` Pedro Alves
2012-05-21 21:35 ` Pedro Alves
2012-05-21 21:53 ` Michael Eager
2012-05-21 22:48 ` Maciej W. Rozycki
2012-05-22 0:16 ` Michael Eager
2012-05-22 10:17 ` Pedro Alves
2012-05-22 13:16 ` Maciej W. Rozycki
2012-05-22 13:32 ` Pedro Alves
2012-05-22 15:10 ` Move store_waitstatus to inf-child.c (was: Re: MIPS Linux signals) Pedro Alves
2012-05-22 15:40 ` MIPS Linux signals Michael Eager
2012-05-22 16:02 ` Pedro Alves
2012-05-22 18:14 ` Michael Eager
2012-05-22 18:31 ` Pedro Alves
2012-05-22 19:32 ` Michael Eager
2012-05-22 22:06 ` Pedro Alves
2012-05-22 16:26 ` Pedro Alves
2012-05-22 10:58 ` Pedro Alves
2012-05-22 19:31 ` Aleksandar Ristovski
2012-05-22 21:55 ` Pedro Alves
2012-05-22 23:29 ` Aleksandar Ristovski
2012-05-23 11:39 ` Pedro Alves
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=4FBA7D30.50500@redhat.com \
--to=palves@redhat.com \
--cc=eager@eagerm.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