From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23972 invoked by alias); 24 Feb 2009 10:42:01 -0000 Received: (qmail 23961 invoked by uid 22791); 24 Feb 2009 10:42:00 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Feb 2009 10:41:54 +0000 Received: from d23relay02.au.ibm.com (d23relay02.au.ibm.com [202.81.31.244]) by e23smtp08.au.ibm.com (8.13.1/8.13.1) with ESMTP id n1OAfp6d029710 for ; Tue, 24 Feb 2009 21:41:51 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay02.au.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1OAg9N9893120 for ; Tue, 24 Feb 2009 21:42:09 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1OAfpSG030857 for ; Tue, 24 Feb 2009 21:41:51 +1100 Received: from [9.124.124.72] (vinaysridhar.in.ibm.com [9.124.124.72]) by d23av01.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1OAfmmc030812; Tue, 24 Feb 2009 21:41:48 +1100 Subject: Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread From: Vinay Sridhar To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com, Pedro Alves In-Reply-To: <20090223140812.GA10946@caradoc.them.org> References: <20090211155300.GA22689@caradoc.them.org> <1234417406.6489.3.camel@localhost.localdomain> <20090215182233.GA24660@caradoc.them.org> <1234779868.4861.7.camel@localhost.localdomain> <20090216150403.GA27072@caradoc.them.org> <1234849907.4215.7.camel@localhost.localdomain> <20090217132951.GA32041@caradoc.them.org> <1235102359.4719.3.camel@localhost.localdomain> <20090222194316.GA21483@caradoc.them.org> <1235379059.10038.12.camel@localhost.localdomain> <20090223140812.GA10946@caradoc.them.org> Content-Type: text/plain; charset=UTF-8 Date: Tue, 24 Feb 2009 10:57:00 -0000 Message-Id: <1235471980.4894.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: 2009-02/txt/msg00455.txt.bz2 On Mon, 2009-02-23 at 09:08 -0500, Daniel Jacobowitz wrote: > On Mon, Feb 23, 2009 at 02:20:59PM +0530, Vinay Sridhar wrote: > > > If they are, and they do not have private info set, what added them to > > > the thread list? I missed one function; maybe they were added by > > > add_thread_silent? > > > > > > > yes, add_thread_silent () is called on the threads. Its called for the > > parent from fork_inferior () and for the child threads from > > add_thread_with_info () > > Thanks, now we're making progress. > > Pedro, copying you because this is related to always-a-thread. > > What's happening here is that we go to look up a TLS variable. > We have some threads in the thread list with thread->private set, but > the main thread does not have it set - thread_db never added it, > fork_inferior did. So we don't really know about it. > > Vinay, thread_db_find_new_threads should have been called when the > program started up. Yes, I did see thread_db_find_new_threads being called. > Was find_new_threads_callback called for > the main thread during that process? If so, was ti_tid == 0? > That shouldn't happen unless the program is staticly linked. > find_new_thread_callback was called on the parent thread, before the other threads were initialised. (I was able to trace 2 of these calls on the parent thread though, not sure why). And yes, "ti_tid" was set to 0 for the parent thread.