From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32266 invoked by alias); 2 Dec 2005 00:55:48 -0000 Received: (qmail 32259 invoked by uid 22791); 2 Dec 2005 00:55:47 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 00:55:42 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jB20tesf016573 for ; Thu, 1 Dec 2005 19:55:40 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jB20tZV16341 for ; Thu, 1 Dec 2005 19:55:35 -0500 Received: from localhost.localdomain (vpn50-83.rdu.redhat.com [172.16.50.83]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id jB20tYT6001361 for ; Thu, 1 Dec 2005 19:55:34 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id jB20tSmI011650 for ; Thu, 1 Dec 2005 17:55:29 -0700 Date: Fri, 02 Dec 2005 00:55:00 -0000 From: Kevin Buettner To: rda@sources.redhat.com Subject: [commit] Fix some thread_db event model bugs Message-ID: <20051201175528.1ebc8246@ironwood.lan> Organization: Red Hat X-Mailer: Sylpheed-Claws 0.9.12cvs173.1 (GTK+ 2.4.14; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact rda-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: rda-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00008.txt.bz2 I found these bugs recently while debugging against an am33 target. One is a fairly old bug and was likely not noticed 'til now due to the fact that a software singlestep target is required to see it. The other bug is one that I introduced recently when I revised thread-db.c to not always update the thread list. * thread-db.c (handle_thread_db_event): Allow underlying target a chance to look at the wait status too. (thread_db_check_child_state): Ensure that there's a thread list to work with when using the thread_db event model. Index: thread-db.c =================================================================== RCS file: /cvs/src/src/rda/unix/thread-db.c,v retrieving revision 1.16 diff -u -p -r1.16 thread-db.c --- thread-db.c 8 Nov 2005 21:58:36 -0000 1.16 +++ thread-db.c 2 Dec 2005 00:48:28 -0000 @@ -1853,6 +1853,9 @@ handle_thread_db_event (struct child_pro /* We don't have any new status to report... */ return 1; } + /* Give underlying target a chance to look at the wait status. This + is necessary for software singlestep to work correctly. */ + handle_waitstatus (process, w); /* Re-insert the event breakpoints. */ insert_thread_db_event_breakpoints (serv); @@ -2146,11 +2149,19 @@ thread_db_check_child_state (struct chil process->stop_signal, (unsigned long) debug_get_pc (process->serv, process->pid)); -#if ALWAYS_UPDATE_THREAD_LIST - /* Update the thread list, and attach to (and thereby stop) - any new threads we find. */ - update_thread_list (process); +#if !ALWAYS_UPDATE_THREAD_LIST + /* The thread_db event model requires that `event_thread' (see + below) gets set correctly, but this won't happen unless there's + a thread list to search. So, if the thread_list is empty and + we're using the thread_db event model, we need to update the + thread list. */ + if (thread_list == NULL && using_thread_db_events) #endif + { + /* Update the thread list, and attach to (and thereby stop) + any new threads we find. */ + update_thread_list (process); + } process->event_thread = thread_list_lookup_by_lid (process->pid);