Re: MIPS Linux signals

Pedro Alves
2012-05-22T21:55:49Z

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