From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24580 invoked by alias); 26 Aug 2010 19:47:53 -0000 Received: (qmail 24565 invoked by uid 22791); 26 Aug 2010 19:47:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Aug 2010 19:47:47 +0000 Received: (qmail 17694 invoked from network); 26 Aug 2010 19:47:45 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Aug 2010 19:47:45 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [RFA/NEWS] Re: PR corefile/8210: Linux core files should use linux-thread-db.c Date: Thu, 26 Aug 2010 19:47:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: bauerman@br.ibm.com References: <201008142005.49256.pedro@codesourcery.com> <201008262013.28049.pedro@codesourcery.com> <83fwy1maj7.fsf@gnu.org> In-Reply-To: <83fwy1maj7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008262047.43782.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: 2010-08/txt/msg00450.txt.bz2 On Thursday 26 August 2010 20:36:12, Eli Zaretskii wrote: > It's okay, with two comments: > > > +* GDB now displays pthread_t ids and allows inspecting TLS variables > > + when debugging core dumps on GNU/Linux. > > Suggest to make a shorter header: > > * GDB now supports thread debugging of core dumps on GNU/Linux. > > > + When debugging a core dump generated on a machine not the one used > > + to run GDB, you may need to point GDB at the correct libthread_db > > When debugging a core dump generated on a machine other than the one > used to run GDB, you may need ... Ah, thanks. I was going in circles trying to make that sentence not sound weird, and failing. I've applied the below. -- Pedro Alves 2010-08-26 Pedro Alves * NEWS: Mention libthread_db debugging with core files. --- gdb/NEWS | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) Index: src/gdb/NEWS =================================================================== --- src.orig/gdb/NEWS 2010-08-26 20:33:43.000000000 +0100 +++ src/gdb/NEWS 2010-08-26 20:42:46.000000000 +0100 @@ -37,6 +37,31 @@ expression. Such a watchpoint is never deleted due to it going out of scope. +* GDB now supports thread debugging of core dumps on GNU/Linux. + + GDB now activates thread debugging using the libthread_db library + when debugging GNU/Linux core dumps, similarly to when debugging + live processes. As a result, when debugging a core dump file, GDB + is now able to display pthread_t ids of threads. For example, "info + threads" shows the same output as when debugging the process when it + was live. In earlier releases, you'd see something like this: + + (gdb) info threads + * 1 LWP 6780 main () at main.c:10 + + While now you see this: + + (gdb) info threads + * 1 Thread 0x7f0f5712a700 (LWP 6780) main () at main.c:10 + + It is also now possible to inspect TLS variables when debugging core + dumps. + + When debugging a core dump generated on a machine other than the one + used to run GDB, you may need to point GDB at the correct + libthread_db library with the "set libthread-db-search-path" + command. See the user manual for more details on this command. + *** Changes in GDB 7.2 * Shared library support for remote targets by default