From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17360 invoked by alias); 19 Aug 2008 17:08:50 -0000 Received: (qmail 17351 invoked by uid 22791); 19 Aug 2008 17:08:49 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Aug 2008 17:08:00 +0000 Received: (qmail 7545 invoked from network); 19 Aug 2008 17:07:58 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Aug 2008 17:07:58 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: AIX, always a thread, experimental patch Date: Tue, 19 Aug 2008 17:08:00 -0000 User-Agent: KMail/1.9.9 Cc: Ulrich Weigand MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_b4vqIxMekvVm0yx" Message-Id: <200808191808.43011.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00522.txt.bz2 --Boundary-00=_b4vqIxMekvVm0yx Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 2401 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 --Boundary-00=_b4vqIxMekvVm0yx Content-Type: text/x-diff; charset="utf-8"; name="aix_thread_always_a_thread.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="aix_thread_always_a_thread.diff" Content-length: 3533 2008-08-19 Pedro Alves * 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); } --Boundary-00=_b4vqIxMekvVm0yx--