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]

Fix non-stop + extended-remote + !multi-process target open


This fixes one bug when opening a connection in extended-remote (I know of one more),
against a target that doesn't support the multi-process thread id extensions,
and the remote happens to not be controlling any inferior yet.  If in non-stop, and
the remote doesn't support the multi-process extensions, since we can't know the pid
of the remote process, we were setting inferior_ptid early to the magic_null_ptid,
assuming any threads would be reported immediately.  But if there were no threads
under the stubs control yet (extended-remote allows this), it is wrong to leave
inferior_ptid pointing at something non-null_ptid.  In this dangling state, we'd
get internal_error's when we go and try to attach to a remote process, because
a non-null ptid is assumed to be in the thread list --- inferior_thread () asserts if it
isn't.  The assertion happened to triggers first in infrun.c:clear_proceed_status, but
it could happen in many other places.

Checked in.

-- 
Pedro Alves
2008-12-12  Pedro Alves  <pedro@codesourcery.com>

	* remote.c (read_ptid): If we don't know about any inferior yet,
	use the pid of magic_null_ptid.
	(remote_start_remote): In the non-stop mode case, don't set
	inferior_ptid to magic_null_ptid here.

---
 gdb/remote.c |   16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c	2008-12-02 16:08:44.000000000 +0000
+++ src/gdb/remote.c	2008-12-02 16:08:45.000000000 +0000
@@ -1527,8 +1527,13 @@ read_ptid (char *buf, char **obuf)
   pp = unpack_varlen_hex (p, &tid);
 
   /* Since the stub is not sending a process id, then default to
-     what's in inferior_ptid.  */
-  pid = ptid_get_pid (inferior_ptid);
+     what's in inferior_ptid, unless it's null at this point.  If so,
+     then since there's no way to know the pid of the reported
+     threads, use the magic number.  */
+  if (ptid_equal (inferior_ptid, null_ptid))
+    pid = ptid_get_pid (magic_null_ptid);
+  else
+    pid = ptid_get_pid (inferior_ptid);
 
   if (obuf)
     *obuf = pp;
@@ -2576,13 +2581,6 @@ remote_start_remote (struct ui_out *uiou
 	 controlling.  We default to adding them in the running state.
 	 The '?' query below will then tell us about which threads are
 	 stopped.  */
-
-      /* If we're not using the multi-process extensions, there's no
-	 way to know the pid of the reported threads; use the magic
-	 number.  */
-      if (!remote_multi_process_p (rs))
-	inferior_ptid = magic_null_ptid;
-
       remote_threads_info ();
     }
   else if (rs->non_stop_aware)

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