Re: MIPS Linux signals

[Michael Eager <eager@eagerm.com>]

On 05/22/2012 03:17 AM, Pedro Alves wrote:

> I agree that the current naming is confusing, but I'll point out why I think
> target_signal_from_host is actually correct, and then conclude with renaming
> suggestions to avoid the confusion, and fix the naming of the gdbarch hook, which
> I think is not correct.  We have
>
> enum target_signal
> {
> ...
>    TARGET_SIGNAL_FOO,
>    TARGET_SIGNAL_BAR,
> ...
> };
>
> which represents GDB's internal signal numbers.AFAIK, the "target_" prefix
> naming in this case is just a natural choice, given that that's how we name
> everything behind the target_ops abstraction -- target_read_memory,
> target_resume, etc., etc. (target.h) -- the mechanism that is mostly about
> abstracting the details of handling the target's debug interface API.

As you say, these are GDB's internal values.  They are not the values used on
(some) targets.   They are not the values used by (some) host systems either.

There's a difference between target_read_memory() which actually reads a
value from the memory on the target, and target_signal which is not the
value from the target, but a translated internal value.

> So this explains the "target_signal_from_" part of the function's signature.

Not for me.  :-)

> The "from_host" part is really correct: this really is a host function -- think in
> terms of autoconf's notion of build vs host vs target.  It only makes sense to call
> it in native code (native == host).  And in fact, that's what happens.

GDB tends to muddle host and target.  Or perhaps the confusion is between the
host environment and GDB's internal data structures.

There is no need to translate signal numbers from the host system environment
to the target system environment.  There is a need to translate from GDB's internal
numbering to the target numbering, and vice versa.  There is nothing significant
about the host's signal numbering that should affect how GDB works with the target,
whether the target is a native process, remote system, or core file.

When target=host, translating from the target's signal numbering to GDB's
internal numbering should be identical to the case when target!=host.

target_signal_from_host() makes no sense to me.  I don't have a host core
file; it's a target core file.

> gdbserver is always native, so always host.

That's the exception.  But that should still use the target to/from internal
translation function.

> enum target_signal =>  enum gdb_signal
>
> target_signal_from_host =>  gdb_signal_from_host (or gdb_signal_from_host_signal)
> target_signal_to_host =>  gdb_signal_to_host (or gdb_signal_to_host_signal)
>
> gdbarch_target_signal_from_host =>  gdbarch_gdb_signal_from_target (or gdbarch_gdb_signal_from_target_signal)
> gdbarch_target_signal_to_host =>  gdbarch_gdb_signal_to_target (or gdbarch_gdb_signal_to_target_signal)

OK, but I'd recommend
   target_signal_from_host =>  gdb_signal_from_target
   target_signal_to_host =>  gdb_signal_to_target

This is symmetric with the gdbarch_ functions and clear that the function
translates to/from target system values, not the host system.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077