MIPS Linux signals

[Aleksandar Ristovski]

On 12-05-22 05:55 PM, Pedro Alves wrote:
> On 05/22/2012 08:31 PM, Aleksandar Ristovski wrote:
>
>> On 12-05-22 06:57 AM, Pedro Alves wrote:
>
>
>>> Aleksandar, we're discussing gdbarch_target_signal_from_host and
>>> gdbarch_target_signal_to_host.  It turns out that uses to either of those
>>> were never added to GDB.  gdbarch_target_signal_FROM_host's purpose is clear,
>>> and we're about to add a (new) use to fix the same situation you ran into at the
>>> time (cross core debugging).  I'm wondering if you ever found a use for
>>> gdbarch_target_signal_TO_host that we should consider, though.
>>>
>>
>> The API was added to introduce consistency between gdb's view of target's numeric signal values and actual
>
>> numerical signal values of the target. In general case, they should *not* be viewed as the same, but rather
>>   as distinct numeric sets which happen to have common names. When cross-examining a core this becomes very
>> obvious, but it is also very obvious when debugging remote target which has different numerical values for signals.
>
>>
>> I use both from_host and to_host.
>
>
> I'm confused on the "when debugging remote target which has different numerical values for signals"
> part, because the target is not supposed to send anything but the generic "enum target_signal" back to
> GDB core.  The core should never need to do such translation with any target other than the
> core target.

In my case, translation happens in remote-nto.c which is our remote 
target. (our functional equivalent of gdbserver does not really know 
about gdb's enum target_signal).


>
>> That being said, I'm not sure why I never submitted actual uses for nto target... I have it in our repository.
>>
>>
>> Looking at the code now, I see why. I use it in our remote target (we have our own) and thus perform translation on-the-fly. Gdb receives correct GDB version as well as target (when gdb sends it).
>
>
> So it sounds like there's no real use for the gdbarch method in _common_ code then, right?  If
> that's the case, we should zap it from the FSF tree until we find such a use.
>

Fine by me.

(FWIW, I like renaming enum target_signal to gdb_signal; it will clear 
up some confusion).