Re: [RFC/PATCH] Add new internal variable $_signo

[Pedro Alves <palves at redhat dot 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