This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MIPS Linux signals


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]