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 04:40 PM, Michael Eager wrote:
> 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. :-)
Could it be you mean "I agree, but I think the naming
of the enum could be clearer/better"? The enum is called "enum target_signal".
So the function that converts an enum target_signal from something else
is called "target_signal_from_...". That much seems clear enough to 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.
Not sure what you're alluding to.
> 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.
Correct. Is that in disagreement with anything I said? It's just that GDB's
internal signal numbering is called "enum target_signal".
>
> 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.
It makes sense in the native/host-only parts of GDB. linux-nat.c and friends, etc.
> I don't have a host core file; it's a target core file.
Yes, that's why in corelow.c the conversion goes through the gdbarch method.
corelow.c is not a native/host-only file (ideally anyway). We have the
target_signal_from_host fallback for old ports that haven't yet bothered
to convert to modern mechanisms, and can't cross-debug cores.
>
>> gdbserver is always native, so always host.
>
> That's the exception.
So is all the native-debugger code within GDB; code which we want
to actually split out of gdb and share/merge with gdbserver.
> But that should still use the target to/from internal
> translation function.
Correct.
>
>> 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.
But it's not what the functions do... They really convert from the host
system signals, not the target's. I think the symmetry will only lead to
people getting confused (which one to call in common/target-independent code?).
--
Pedro Alves