From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12869 invoked by alias); 23 Feb 2009 08:53:46 -0000 Received: (qmail 12860 invoked by uid 22791); 23 Feb 2009 08:53:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from e28smtp06.in.ibm.com (HELO e28smtp06.in.ibm.com) (59.145.155.6) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Feb 2009 08:53:40 +0000 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by e28smtp06.in.ibm.com (8.13.1/8.13.1) with ESMTP id n1N8r6YK022500 for ; Mon, 23 Feb 2009 14:23:06 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1N8oJOh3416158 for ; Mon, 23 Feb 2009 14:20:19 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.13.1/8.13.3) with ESMTP id n1N8r69I003904 for ; Mon, 23 Feb 2009 19:53:06 +1100 Received: from [9.124.124.72] ([9.124.124.72]) by d28av03.in.ibm.com (8.13.1/8.12.11) with ESMTP id n1N8r60x003901; Mon, 23 Feb 2009 19:53:06 +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 In-Reply-To: <20090222194316.GA21483@caradoc.them.org> References: <20090204132851.GA9935@caradoc.them.org> <1234341068.13249.4.camel@localhost.localdomain> <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> Content-Type: text/plain Date: Mon, 23 Feb 2009 09:20:00 -0000 Message-Id: <1235379059.10038.12.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00438.txt.bz2 On Sun, 2009-02-22 at 14:43 -0500, Daniel Jacobowitz wrote: > On Fri, Feb 20, 2009 at 09:29:19AM +0530, Vinay Sridhar wrote: > > I placed a break on "add_thread" as you suggested. It doesn't seem to be > > hit at all, for any of the threads. > > BTW, I'm using GNU gdb (GDB) 6.8.50.20090216. > > At the time of the original error, are all your threads in the thread > list? GDB's internal thread_list variable, not the result of "info > threads", which will check for new threads. > At the time of the error, all the threads are in the thread_list. All threads but the parent thread have private field filled. (gdb) p thread_list->private {pid = 12022, lwp = 12027} $7 = (struct private_thread_info *) 0x10870530 (gdb) p thread_list->next->private {pid = 12022, lwp = 12026} $8 = (struct private_thread_info *) 0x108a7b80 (gdb) p thread_list->next->next->private {pid = 12022, lwp = 12025} $9 = (struct private_thread_info *) 0x10844e70 (gdb) p thread_list->next->next->next->private {pid = 12022,lwp = 12022} $10 = (struct private_thread_info *) 0x0 > 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 ()