From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22213 invoked by alias); 10 Jul 2008 17:15:39 -0000 Received: (qmail 22203 invoked by uid 22791); 10 Jul 2008 17:15:39 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 10 Jul 2008 17:15:20 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id E2ED998415; Thu, 10 Jul 2008 17:15:18 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id C6F7E98337; Thu, 10 Jul 2008 17:15:18 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KGzji-0005Al-5V; Thu, 10 Jul 2008 13:15:18 -0400 Date: Thu, 10 Jul 2008 17:15:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [non-stop] 08/10 linux native support Message-ID: <20080710171518.GA19554@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <200806152205.49241.pedro@codesourcery.com> <200807020434.50543.pedro@codesourcery.com> <20080707182009.GE1778@caradoc.them.org> <200807101627.50156.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807101627.50156.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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-07/txt/msg00151.txt.bz2 On Thu, Jul 10, 2008 at 04:27:49PM +0100, Pedro Alves wrote: > > This (the thread_db_attach_lwp version) looks reasonable to me. Ugly, > > but reasonable. Why do we need the parent's data? > > Due to this: > > (gdb) r& > Starting program: /home/pedro/gdb/tests/threads32 > (gdb) [Thread debugging using libthread_db enabled] > [New Thread 0xf7df0b90 (LWP 24154)] > [New Thread 0xf75efb90 (LWP 24155)] > info threads > 3 Thread 0xf75efb90 (LWP 24155) (running) > 2 Thread 0xf7df0b90 (LWP 24154) (running) > * 1 LWP 24151 (running) Why didn't this thread get identified at the shared library event, when libthread_db was loaded? It already existed by then, being the main thread. > The issue here is that have_threads returns true here: > > linux-thread-db.c:thread_db_wait > ... > /* If we do not know about the main thread yet, this would be a good time to > find it. */ > if (ourstatus->kind == TARGET_WAITKIND_STOPPED && !have_threads ()) > thread_db_find_new_threads (); > > ... because there are already threads that thread_db learned about, > so we'd not look for info regarding the main thread. Which ought to fix this too; if we identify threads as soon as libthread_db is activated then we won't reach this situation. If there's other places where we add a newly created thread without walking all threads, then they can get a call similar to the above (that's for the static application case where we won't get a handy shared library event for libpthread.so). -- Daniel Jacobowitz CodeSourcery