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 12-05-22 05:55 PM, Pedro Alves wrote:
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.

In my case, translation happens in remote-nto.c which is our remote target. (our functional equivalent of gdbserver does not really know about gdb's enum target_signal).




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.


Fine by me.


(FWIW, I like renaming enum target_signal to gdb_signal; it will clear up some confusion).


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