From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29807 invoked by alias); 15 Apr 2008 03:05:40 -0000 Received: (qmail 29771 invoked by uid 22791); 15 Apr 2008 03:05:39 -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 03:05:12 +0000 X-IronPort-AV: E=Sophos;i="4.25,658,1199692800"; d="scan'208";a="72773348" Received: from discus.brocade.com ([192.168.126.240]) by mx10.brocade.com with ESMTP; 14 Apr 2008 20:05:10 -0700 Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2 [192.168.126.212]) by discus.brocade.com (Postfix) with ESMTP id B837D2383A4; Mon, 14 Apr 2008 20:05:10 -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); Mon, 14 Apr 2008 20:05:09 -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 06:54:00 -0000 Message-ID: In-Reply-To: <1208222665.3690.4.camel@localhost.localdomain> From: "Icarus Sparry" To: "Michael Snyder" 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/msg00120.txt.bz2 > -----Original Message----- > From: Michael Snyder [mailto:msnyder@specifix.com] > Sent: Monday, April 14, 2008 6:24 PM > To: Icarus Sparry > Cc: gdb@sourceware.org > Subject: Re: GDB doesn't display thread_id while debugging a core file >=20 > On Mon, 2008-04-14 at 18:01 -0700, Icarus Sparry wrote: > > Last November there was some discussion on this topic, which ended with > > Daniel Jacobowitz saying in > > > > http://sourceware.org/ml/gdb/2007-08/msg00068.html > > > > If we assume that the host's libthread_db will either recognize > > the > > core file and do the right thing, or reject the core file, then > > we can > > write a small target layer that uses it on top of corelow.c in a > > similar way to how linux-thread-db.c / proc-service.c use > > linux-nat.c. > > > > It's just a matter of testing that on a couple of different > > setups, > > like LinuxThreads and cross debuggers, to see how it behaves. > > Or > > doesn't behave. > > > > > > Being able to access variables declared with __thread in core files > > would certainly be useful. Could someone give some reasonable guess of > > the amount of effort required to do this? In particular for a powerpc32 > > corefile from a linux process with NPTL being debugged on an x86 linux > > box. >=20 > Off hand, I would not expect the libthread_db library to > be able to do anything useful with a corefile from a different > architecture. 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.