Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>,
	       "'GDB Patches'" <gdb-patches@sourceware.org>
Subject: Re: [RFC/PATCH] Add new internal variable $_signo
Date: Mon, 17 Jun 2013 17:02:00 -0000	[thread overview]
Message-ID: <51BF407C.3040905@redhat.com> (raw)
In-Reply-To: <m3vc5gwhue.fsf@redhat.com>

On 06/14/2013 09:35 PM, Sergio Durigan Junior wrote:
> On Friday, June 14 2013, Pedro Alves wrote:
> 
>> gdb_signal_to_host is the fallback (and having a fallback is sort of a
>> hack).  The right signal number is the target's not the host's.  We
>> have gdbarch_gdb_signal_from_target for the opposite direction, but not
>> gdbarch_gdb_signal_to_target...  Having to bake the target OS's signal
>> numbers into GDB is a bit unfortunate, though we could get around it
>> at some point if we wanted by extending the RSP, and/or adding a python
>> hook.
> 
> I was looking for a target variant but found none.  I'm not sure what
> you mean with your comment.  

The right signal conversion is gdb signal <-> target signal.
gdb_signal_to_HOST only works for native debugging, because in that
case target == host.  See in corelow.c:

      /* If we don't have a CORE_GDBARCH to work with, assume a native
	 core (map gdb_signal from host signals).  If we do have
	 CORE_GDBARCH to work with, but no gdb_signal_from_target
	 implementation for that gdbarch, as a fallback measure,
	 assume the host signal mapping.  It'll be correct for native
	 cores, but most likely incorrect for cross-cores.  */
      enum gdb_signal sig = (core_gdbarch != NULL
			     && gdbarch_gdb_signal_from_target_p (core_gdbarch)
			     ? gdbarch_gdb_signal_from_target (core_gdbarch,
							       siggy)
			     : gdb_signal_from_host (siggy));


The same comment applies for reverse conversions (gdb -> target).  We
just don't do any in GDB at present.  These new convenience variables
would be the first such uses.

> Are you suggesting that I take care of this as well?

I'm suggesting that using gdb_signal_to_host only does the
right thing with native debugging, and that the proper conversion
involves adding a gdbarch_gdb_signal_to_target hook.  Given it doesn't
exist, it needs to be written...

(This actually negates my previous comment on $_signo existing
for all targets...)

Then I mumbled that this target signal -> gdb signal -> target signal
conversions are unfortunate, and that we could consider bypassing
them, by either (or both) extending the target interfaces to pass
along the original target signal (the signal numbers that pass around
in the remote protocol are GDB signal numbers, not the target signals),
and/or adding a python hook to aid in the conversion (so support
for random embedded RTOSs would be added without changing gdb).

> In the meantime, I will leave the code as-is, i.e., without doing any
> kind of conversion on infrun.c

-- 
Pedro Alves


  reply	other threads:[~2013-06-17 16:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-14  2:39 Sergio Durigan Junior
2013-06-14  7:49 ` Eli Zaretskii
2013-06-16  6:08   ` Sergio Durigan Junior
2013-06-14  8:59 ` Mark Kettenis
2013-06-14  9:37 ` Pierre Muller
2013-06-14 17:59   ` Sergio Durigan Junior
2013-06-14 20:36     ` Pedro Alves
2013-06-15  6:46       ` Sergio Durigan Junior
2013-06-17 17:02         ` Pedro Alves [this message]
2013-06-14 17:58 ` Pedro Alves
2013-06-16  5:57   ` Sergio Durigan Junior
2013-06-16  6:25     ` Sergio Durigan Junior
2013-06-17 17:20     ` Pedro Alves
2013-07-17 18:41 ` Tom Tromey

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=51BF407C.3040905@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pierre.muller@ics-cnrs.unistra.fr \
    --cc=sergiodj@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