From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22994 invoked by alias); 24 Feb 2009 15:58:27 -0000 Received: (qmail 22986 invoked by uid 22791); 24 Feb 2009 15:58:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Feb 2009 15:58:22 +0000 Received: (qmail 23587 invoked from network); 24 Feb 2009 15:58:19 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Feb 2009 15:58:19 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread Date: Tue, 24 Feb 2009 18:52:00 -0000 User-Agent: KMail/1.9.10 Cc: Vinay Sridhar , gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com References: <20090211155300.GA22689@caradoc.them.org> <1235472610.4894.14.camel@localhost.localdomain> <20090224153153.GA7032@caradoc.them.org> In-Reply-To: <20090224153153.GA7032@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200902241558.31703.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: 2009-02/txt/msg00468.txt.bz2 On Tuesday 24 February 2009 15:31:53, Daniel Jacobowitz wrote: > 81 =A0 =A0 =A0 =A0 =A0 =A0/* Verify that this thread's pid field matches = the child PID. > 82 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If its pid field is negative, it's about t= o do a fork or it > 83 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is the sole thread in a fork child. =A0*/ Boo, I'm on glibc 2.7, which doesn't have this check, but I see it in glibc-2.9 sources... > It's checking that the PID (not TID) matches proc_handle.pid. =A0We need > to find another way to read from a stopped thread, since if we put any > other PID there, we get no threads. =A0I would suggest expanding > ps_prochandle to include a memory thread as ptid_t. =A0 Right, I'll take this. Funny, I was actually noticing the other day that the proc service implementation in sol-threads.c passes a ptid already, and I was considering making sol-threads.c use proc-service.c: /* This struct is defined by us, but mainly used for the proc_service interface. We don't have much use for it, except as a handy place to get a real PID for memory accesses. */ struct ps_prochandle { ptid_t ptid; }; > We always try to=20 > read from the most recently added stopped thread, since the lwp_list > gets additions at the front. >=20 --=20 Pedro Alves