Re: MIPS Linux signals

[Pedro Alves <palves@redhat.com>]

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