From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31744 invoked by alias); 15 Apr 2008 01:24:55 -0000 Received: (qmail 31734 invoked by uid 22791); 15 Apr 2008 01:24:55 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Apr 2008 01:24:27 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 6ECAA3BCCF; Mon, 14 Apr 2008 18:24:25 -0700 (PDT) Subject: Re: GDB doesn't display thread_id while debugging a core file From: Michael Snyder To: Icarus Sparry Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Tue, 15 Apr 2008 03:10:00 -0000 Message-Id: <1208222665.3690.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00119.txt.bz2 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. Off hand, I would not expect the libthread_db library to be able to do anything useful with a corefile from a different architecture.