[Hurd/gnu-nat] Fix old "signal-thread" command regression.
authorPedro Alves <palves@redhat.com>
Wed, 18 Sep 2013 12:00:06 +0000 (12:00 +0000)
committerPedro Alves <palves@redhat.com>
Wed, 18 Sep 2013 12:00:06 +0000 (12:00 +0000)
commitc8d37639e3a23ed7349a17c3ac4d1407113eaa17
treeb6f75cc742bb7a250b2aada01a1c7c25406abef4
parent71926e28107e299c0fae9892d46277aeff0a0209
[Hurd/gnu-nat] Fix old "signal-thread" command regression.

By inspection, I noticed that when I made the gnu-nat use
ptid(pid,0,tid) to represent a thread, instead of using ptid(tid,0,0),
in <https://sourceware.org/ml/gdb-patches/2008-08/msg00175.html>, I
introduced a bug.

The change was:

   else
     {
-      int tid = PIDGET (thread_id_to_pid (atoi (args)));
+      int tid = ptid_get_tid (thread_id_to_pid (atoi (args)));
       if (tid < 0)
  error (_("Thread ID %s not known.  Use the \"info threads\" command to\n"
         "see the IDs of currently known threads."), args);

and thread_id_to_pid does:

 ptid_t
 thread_id_to_pid (int num)
 {
   struct thread_info *thread = find_thread_id (num);

   if (thread)
     return thread->ptid;
   else
     return pid_to_ptid (-1);
 }

(pid_to_ptid (-1) is the same as minus_one_ptid.)

So before, we were really looking at the pid, where thread_id_to_pid
stores the -1.

The right fix is to compare the whole ptid to minus_one_ptid, of
course.

Completely untested, but I think it's obvious enough, so I went ahead
and put it in.

gdb/
2013-09-18  Pedro Alves  <palves@redhat.com>

* gnu-nat.c (set_sig_thread_cmd): Compare the thread's ptid to
minus_one_ptid instead of looking at the ptid's tid field and
comparing that to -1.
gdb/ChangeLog
gdb/gnu-nat.c