This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: MIPS Linux signals
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