Re: MIPS Linux signals

[Pedro Alves <palves@redhat.com>]

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.

> 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.

-- 
Pedro Alves