From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21626 invoked by alias); 15 Apr 2008 20:17:16 -0000 Received: (qmail 21617 invoked by uid 22791); 15 Apr 2008 20:17:16 -0000 X-Spam-Check-By: sourceware.org Received: from mx10.brocade.com (HELO mx10.brocade.com) (208.185.105.18) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Apr 2008 20:16:58 +0000 X-IronPort-AV: E=Sophos;i="4.25,661,1199692800"; d="scan'208";a="72969066" Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 15 Apr 2008 13:16:56 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id 38D4323839C; Tue, 15 Apr 2008 13:16:56 -0700 (PDT) Received: from HQ-EXCH-5.corp.brocade.com ([10.3.8.83]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Apr 2008 13:16:56 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: GDB doesn't display thread_id while debugging a core file Date: Tue, 15 Apr 2008 20:46:00 -0000 Message-ID: In-Reply-To: <1208282686.3690.14.camel@localhost.localdomain> From: "Icarus Sparry" To: "Michael Snyder" , "Daniel Jacobowitz" Cc: Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00140.txt.bz2 > -----Original Message----- > From: Michael Snyder [mailto:msnyder@specifix.com] > Sent: Tuesday, April 15, 2008 11:05 AM > To: Daniel Jacobowitz > Cc: Icarus Sparry; gdb@sourceware.org > Subject: Re: GDB doesn't display thread_id while debugging a core file >=20 > On Mon, 2008-04-14 at 23:10 -0400, Daniel Jacobowitz wrote: > > On Mon, Apr 14, 2008 at 08:04:52PM -0700, Icarus Sparry wrote: > > > If I understand what Daniel was saying correctly, the libthread_db > file > > > would be an x86 shared library, but it would be configured to handle > > > ppc32 elf core files, in the same way as the executable > > > powerpc-linux-gdb program that currently we have running on the x86 > > > machines. > > > > No. You would have to rely on the native x86 library luckily doing > > the right thing. >=20 > And that's highly unlikely. Data structures would likely > have different fields and sizes and such. >=20 > If someone wanted to make a project of building a cross-libthread-db, > I'm sure it could be done -- but it would be a project. I am obviously not making myself clear! It is "obvious" to me that one needs a "cross-libthread-db" library, for example one that is an x86 executable but is configured to handle threading on a ppc32 with NPTL as I described above. I do not expect things like this to come for free on most systems. The question I hoped I had asked was "How much effort is it?" The program I am interested in at the moment only has a single __thread variable, which is used to index many arrays. I have a number of choices, ranging from write a function in gdb to get the value of this particular variable, to fixing gdb so it can get the information correctly from the core for all thread local variables. The latter is going to be more work, but makes gdb a better debugger for everyone.=20