Re: MIPS Linux signals

[Michael Eager <eager@eagerm.com>]

On 05/22/2012 11:30 AM, Pedro Alves wrote:
> On 05/22/2012 07:14 PM, Michael Eager wrote:
>
>> On 05/22/2012 09:01 AM, Pedro Alves wrote:
>>
>>>>> 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?).
>>
>> If you are running GDB on a Windows host, for example, what host
>> system signals are you translating?
>
>
> There's only be one such call -- the one from within corelow.c, if there's no
> gdbarch_target_signal_from_host callback installed.  (The Windows ports don't call
> target_signal_from_host anywhere (windows-nat.c and friends).  And in that case, if
> you e.g., load a cygwin core, the target_signal_from_host fallback will try to
> convert the signal number as if it was a host signal number.  If you're running g
> b on a cygwin host, you'll happen to get the right values.  If you're debugging
> a core (that same core or of some other non-native arch) with a cross debugger, with
> a mingw hosted gdb, then target_signal_from_host will _still_ translate the signal
> numbers found in mingw's signal.h header.  For reference, those are:
>
> #define SIGINT          2       /* Interactive attention */
> #define SIGILL          4       /* Illegal instruction */
> #define SIGFPE          8       /* Floating point error */
> #define SIGSEGV         11      /* Segmentation violation */
> #define SIGTERM         15      /* Termination request */
> #define SIGBREAK        21      /* Control-break */
> #define SIGABRT         22      /* Abnormal termination (abort) */
>
> All other signal numbers you pass to target_signal_from_host will end up
> as TARGET_SIGNAL_UNKNOWN, due to the bunch of #ifdef SIGFOO bits in
> common/signals.  Obviously, in most cases, this translation will
> be wrong.  But the point to be taken is, target_signal_from_host _always_
> translates the signal number passed as argument as if it was a host
> signal number, no matter what the target really is.

I think the point is that a target signal number should
always be treated as if it were from a target, never
that it was from the host.

All the #ifdefs checking if the host has this signal or that
is confusing.  The only thing that seems relevant to me is
whether the target has these signals.  If it happens that
target==host, then these happen to be equivalent.  But maintaining
a clear target abstraction is a benefit.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077