[commit/target remote] Assertion failure after Ada task switch

[Joel Brobecker <brobecker at adacore dot com>]

Hello,

I noticed the following assertion failure when debugging through
gdbserver today:

    % gdbserver :4444 task_switch
    Process task_switch created; pid = 5390
    Listening on port 4444
    Remote debugging from host 127.0.0.1

And then, from GDB:

        (gdb) target remote :4444
    [...]
    (gdb) b break_me
    Breakpoint 1 at 0x403194: file task_switch.adb, line 44.
    (gdb) cont
    Continuing.
    [New Thread 5717]
    [Switching to Thread 5717]
    
    Breakpoint 1, task_switch.break_me () at task_switch.adb:44
    44         end Break_Me;
    (gdb) info tasks
      ID       TID P-ID Pri State                  Name
       1   1d67010    0  48 Child Termination Wait main_task
       2   1d67d20    1  48 Accept or Select Term  my_callee
       3   1d6b400    1  48 Runnable               my_caller
    (gdb) task 1
    [New Thread 5715]
    /[...]/gdb/thread.c:595: internal-error: is_thread_state:
     Assertion `tp' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n) 

The problem is that we miscomputed the thread PTID associated to the task
we wanted to switch to.  As a result, we returned a PTID that did not
exist, thus preventing us from finding its associated thread_info.

We just forgot to contribute the implementation of the to_get_ada_task_ptid
target_ops routine for the remote protocol.  I think it was because I felt
that the implementation was too simplistic, and needed to be able to
determine the task PTID depending on the what the real target is.
However, in practice, this works for at least all the targets where
AdaCore uses the remote protocol (mostly GNU/Linux, Windows, and LynxOS).
It's a clear improvement over the previous situation, so I decided that
it's better to go in as is, rather than not going in. If we hit a situation
were a more elaborate scheme is needed, we can address the situation then.

Now that I am thinking about it, it's really annoying that we're getting
such a severe error for a failed task switch.  What I will do is add
a check at the end of the task switch routine to see if the new PTID
exists, and if not, error out, rather than blindly setting the
inferior_ptid to this non-existent PTID.  The user will get an error,
so he won't be able to switch tasks, but at least he'll be able to
continue debugging the current thread...

2010-03-07  Joel Brobecker  <brobecker@adacore.com>

        * remote.c (remote_get_ada_task_ptid): New function.
        (init_remote_ops): Set remote_ops.to_get_ada_task_ptid.

Tested on x86_64-linux. Checked in head and branch.

-- 
Joel

diff --git a/gdb/remote.c b/gdb/remote.c
index 7f8ec58..9a49cc9 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -2682,6 +2682,15 @@ remote_threads_extra_info (struct thread_info *tp)
 }
 
 
+/* Implement the to_get_ada_task_ptid function for the remote targets.  */
+
+static ptid_t
+remote_get_ada_task_ptid (long lwp, long thread)
+{
+  return ptid_build (ptid_get_pid (inferior_ptid), 0, lwp);
+}
+
+
 /* Restart the remote side; this is an extended protocol operation.  */
 
 static void
@@ -9679,6 +9688,7 @@ Specify the serial device it is connected to\n\
   remote_ops.to_find_new_threads = remote_threads_info;
   remote_ops.to_pid_to_str = remote_pid_to_str;
   remote_ops.to_extra_thread_info = remote_threads_extra_info;
+  remote_ops.to_get_ada_task_ptid = remote_get_ada_task_ptid;
   remote_ops.to_stop = remote_stop;
   remote_ops.to_xfer_partial = remote_xfer_partial;
   remote_ops.to_rcmd = remote_rcmd;
@@ -10238,3 +10248,4 @@ Show the remote pathname for \"run\""), NULL, NULL, NULL,
   target_buf_size = 2048;
   target_buf = xmalloc (target_buf_size);
 }
+