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/21/2012 03:50 PM, Michael Eager wrote:

> On 05/21/2012 04:03 AM, Pedro Alves wrote:
>> On 05/20/2012 03:02 AM, Michael Eager wrote:
> 
>>>    4 -- Do the multiple layers of wrappers around target_
>>>         signal_{to,from}_host in signals.c serve any purpose?
>>
>> Can you be more specific?  What multiple layers?
> 
> target_signal_to_host() is a wrapper around do_target_signal_to_host().
> 
> target_signal_to_host_p() is a wrapper around do_target_signal_to_host().


Yes, do_target_signal_to_host is a helper for both target_signal_to_host and
target_signal_to_host_p.

> This appears to be only used in gdbserver, where, on MIPS, it will

> return the wrong result.  


Why will it return the wrong result on MIPS/gdbserver?  The common/signals.c
copy built into gdbserver will naturally be built with a MIPS headers, and
should pick up the correct signal defines (SIGINT, etc.).

> Incidentally, gdbserver on MIPS calls
> the X86 target_signal_to_host() to translate signals.  This seems
> confused.  


Now I'm confused.  What do you mean that MIPS gdbserver calls the
X86 target_signal_to_host ?  There's only one target_signal_to_host
function AFAICS.

> If gdb is translating internal signal numbers to the

> target signal numbers, then this seems to be a second translation.


gdbserver internally translates Linux signal numbers to the host
independent internal signal numbers.  We call the latter "target signals",
like we call every method that goes through the "target abstraction"
(target_ops vector) in gdb target_something.  The native signals that
are host dependent (host in the same sense as build vs host vs target
on autoconf), we call them host signals.

On the "wire", RSP packets should contain only the abstracted, internal,
target signal numbers.  So code on gdbserver that talks to ptrace
will need to convert the (native) host signal numbers to target signals
when pushing events to gdbserver common code, and ultimately to GDB.

AFAIK, there's no such second internal signal numbers to target
signal numbers translation in GDB.  The remote target already works with
GDB's own internal signal numbers.

> default_target_signal_to_host() is a wrapper around target_signal_to_host().
> 
> default_target_signal_from_host() is a wrapper around target_signal_from_host().


Right.  gdbarch_target_signal_from_host was invented long after target_signal_from_host
already existed to solve the similar case you ran into.  That is, of when
cross debugging core files.  In that case there's no gdbserver involved to do the
host -> gdb/internal signal conversion for us, so GDB needs to do it, according to
the core's gdbarch.  If there's no such gdbarch callback installed, then we fallback
to the host's default conversion, which with work when debugging native core files.
So you do have the right fix, but the reason why nobody has tripped on this before is
that this only affects cross core debugging, not live gdbserver debugging.

-- 
Pedro Alves


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