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]

AIX, always a thread, experimental patch


Hi,

I've given another look at aix-thread.c, in an effort to make it work with the
always-a-thread changes, and came up with the attached patch.  It is obviously
not finished, but it should point at the direction we should take (I hope).

I still can't tell if rs6000_wait can ever return a ptid different from 
pid_to_ptid(main_process_pid), (or -1).  I assume that GDB is already assuming
that libpthdebug.a is always available, as IBM's docs claim AIX can operate
under an M:N model (aix-threads.c seems to manage that), but there isn't 
anything in rs6000-nat.c managing lwps.  I hope this is not relying on
handle_inferior_event:new_thread_event when debugging a thread app, and 
libpthdebug.a isn't available for some reason or for debugging lwp based
apps that don't use pthreads.  ptids representing the lwps of the same
inferior should be of the form (pid,lwpid,0), not (lwpid,0,0), as it
would happen if rs6000-nat.c relied on new_thread_event.

As I mentioned before, one needs to:

 1) make sure the core never gets a thread related event
    that corresponds to a thread the core doesn't know
    about yet.

 2) #1 implies that every target should register the main thread, even when
    debugging a single-threaded app.
    rs6000-nat.c, being a ptrace based target, already has that covered by
    these:
   http://sourceware.org/ml/gdb-patches/2008-08/msg00505.html
   http://sourceware.org/ml/gdb-patches/2008-08/msg00171.html

 3) #2 implies that a thread_stratum layer should decorate the main thread's
    ptid with thread id info, instead of adding it again. That's 
    thread_change_ptid which is already in the tree.

The attached patch is a first try at it.  Hopefully the changes are 
self-explanatory and the comments point at what to do if things crash badly.

In case I've missed something big, it is my undertanding that the target stack
on AIX is:

threaded:
 aix-thread.c                       (thread_stratum)
 rs6000-nat.c extends inf-ptrace.c  (process_stratum)

non-threaded:
 rs6000-nat.c extends inf-ptrace.c  (process_stratum)

This patch depends on these other patches:

This one for the fork-child.c change:
http://sourceware.org/ml/gdb-patches/2008-08/msg00505.html

This one for the inf-ptrace.c change:
http://sourceware.org/ml/gdb-patches/2008-08/msg00171.html

The thread_change_ptid function is already checked in.

I hope this helps.

-- 
Pedro Alves
2008-08-19  Pedro Alves  <pedro@codesourcery.com>

	* aix-thread.c (sync_threadlists): Claim the main thread.  If no
	thread is found, and we never had thread info bail out early.
	(pd_update): Don't update inferior_ptid here.

---
 gdb/aix-thread.c |   50 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

Index: src/gdb/aix-thread.c
===================================================================
--- src.orig/gdb/aix-thread.c	2008-08-19 16:37:56.000000000 +0100
+++ src/gdb/aix-thread.c	2008-08-19 18:06:04.000000000 +0100
@@ -679,6 +679,7 @@ sync_threadlists (void)
   pthdb_pthread_t pdtid;
   pthread_t pthid;
   pthdb_tid_t tid;
+  infpid = PIDGET (inferior_ptid);
 
   /* Accumulate an array of libpthdebug threads sorted by pthread id.  */
 
@@ -717,6 +718,44 @@ sync_threadlists (void)
 
   qsort (pbuf, pcount, sizeof *pbuf, pcmp);
 
+  /* If the main thread is still listed without extra lwp/tid info,
+     update its ptid and set its private field before synching the
+     lists.  */
+
+  main_thread = find_thread_pid (infpid);
+  if (main_thread)
+    {
+      struct pd_thread *first;
+
+      /* We should have found at least one thread.  */
+      /* Could it be we can get here with no threads while starting up
+         the inferior, and the thread library is still not
+         initialized?  In that case, we'd just better skip over the
+         thread synching?  */
+#if 0
+      gdb_assert (pcount > 0);
+#else
+      if (pcount == 0)
+	{
+	  xfree (pbuf);
+	  return;
+	}
+#endif
+
+      /* Assume the first listed is the main thread.  */
+      first = &pbuf[0];
+
+      main_thread->private = xmalloc (sizeof (struct private_thread_info));
+      main_thread->private->pdtid = first->pdtid;
+      main_thread->private->tid = first->tid;
+
+      /* This also updates inferior_ptid if it is pointing at the main
+	 thread (currently, it always is, but even if is wasn't
+	 because we supported multi-process on AIX, it would be
+	 ok).  */
+      thread_change_ptid (main_thread->ptid, BUILD_THREAD (first->pthid, infpid));
+    }
+
   /* Accumulate an array of GDB threads sorted by pid.  */
 
   gcount = 0;
@@ -727,7 +766,6 @@ sync_threadlists (void)
 
   /* Apply differences between the two arrays to GDB's thread list.  */
 
-  infpid = PIDGET (inferior_ptid);
   for (pi = gi = 0; pi < pcount || gi < gcount;)
     {
       if (pi == pcount)
@@ -816,6 +854,10 @@ pd_update (int set_infpid)
 
   /* Define "current thread" as one that just received a trap signal.  */
 
+  /* Can the bit below now ever return without a valid thread?
+     get_signaled_thread will return 0 if it doesn't find any
+     signalled thread.  If sync_thread_lists didn't find any thread
+     yet, will iter_tid crash on the reference to thread->private?  */
   tid = get_signaled_thread ();
   if (tid != 0)
     thread = iterate_over_threads (iter_tid, &tid);
@@ -824,8 +866,12 @@ pd_update (int set_infpid)
   else
     {
       ptid = thread->ptid;
+#if 0
+      /* sync_threadlists should be already taking care of updating
+	 inferior_ptid, with the thread_change_ptid call.  */
       if (set_infpid)
 	inferior_ptid = ptid;
+#endif
     }
   return ptid;
 }
@@ -940,6 +986,8 @@ new_objfile (struct objfile *objfile)
 static void
 aix_thread_attach (char *args, int from_tty)
 {
+  /* inf-ptrace already adds the thread we attach to, and pd_activate
+     should end up claiming it.  */
   base_target.to_attach (args, from_tty);
   pd_activate (1);
 }

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