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 08:31 PM, Michael Eager wrote:

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


The discussion on the table is not about what should or not should
be design wise.  The discussion is about the confusing
target_signal_from_host method name.  I've given ample explanation of
why that should have "host" in its name.  If we should eliminate that
function and instead provide gdbarch mappings for all targets or not is
a different discussion.  The fact remains that target_signal_from_host
exists, and is widely used.  I'd very much like to retain "host" in its
name to remind the reader that while it exists, its implementation really
is just a mapping from the host signals.  I'm now pretty much done with
repeating the arguments.

> target signal number should always be treated as if it were from a target,

That requires GDB hardcoding signal mappings, and that's what the gdbarch
hook is for.  And that's why I proposed renaming it:

http://sourceware.org/ml/gdb-patches/2012-05/msg00839.html

-- 
Pedro Alves


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