From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5393 invoked by alias); 6 Aug 2010 17:18:02 -0000 Received: (qmail 5367 invoked by uid 22791); 6 Aug 2010 17:18:00 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_BJ,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; Fri, 06 Aug 2010 17:17:56 +0000 Received: (qmail 1716 invoked from network); 6 Aug 2010 17:17:54 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Aug 2010 17:17:54 -0000 From: Pedro Alves To: Hui Zhu Subject: Re: [RFA]corelow.c: Add tid to add_to_thread_list Date: Fri, 06 Aug 2010 17:18:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201008061057.03037.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201008061817.49329.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/msg00079.txt.bz2 On Friday 06 August 2010 17:47:53, Hui Zhu wrote: > The root cause about this issue is the idle thread's pid is 0.=20=20 I'm still interested in answers to the questions I wrote before. Reading the thread again, I understand this a kernel dump core. Am I correct? I've never loaded one in gdb, hence my questions. =46rom your early objdump output,=20 Sections: Idx Name Size VMA LMA File off A= lgn 0 note0 00000a48 0000000000000000 0000000000000000 00000238 2= **0 CONTENTS, READONLY 1 .reg/0 000000d8 0000000000000000 0000000000000000 000002bc 2= **2 CONTENTS 2 .reg 000000d8 0000000000000000 0000000000000000 000002bc 2= **2 CONTENTS 3 .reg/2719 000000d8 0000000000000000 0000000000000000 00000420 2= **2 CONTENTS 4 .reg/0 000000d8 0000000000000000 0000000000000000 00000584 2= **2 CONTENTS 5 .reg/0 000000d8 0000000000000000 0000000000000000 000006e8 2= **2 there's always one thread per core, never more. Is that correct? Is there any indication in the core notes that would allow us to identify this core as a kernel core, not an application core? IMO, since we're debugging at the kernel level, we'd instead use that info to teach bfd info building the .reg sections as, say: 0 note0 00000a48 0000000000000000 0000000000000000 00000238 2= **0 CONTENTS, READONLY 1 .reg/1 000000d8 0000000000000000 0000000000000000 000002bc 2= **2 CONTENTS 2 .reg 000000d8 0000000000000000 0000000000000000 000002bc 2= **2 CONTENTS 3 .reg/2 000000d8 0000000000000000 0000000000000000 00000420 2= **2 CONTENTS 4 .reg/3 000000d8 0000000000000000 0000000000000000 00000584 2= **2 CONTENTS 5 .reg/4 000000d8 0000000000000000 0000000000000000 000006e8 2= **2 that is, identify the cores, not the process the core happened to be running.=20=20 > If > more than one cpu is in idle and each cpu will be a thread in core > file, we got a core file that have some thread ptid is same. > For now, gdb cannot handle it: > struct thread_info * > add_thread_silent (ptid_t ptid) > { If this function hit an internal error in this scenario, then it has a bug. I think Maciej wrote a patch to fix it in our internal tree. I'll try to look for it. Note that with this fixed, gdb would still discard all idle threads but one, and, when accessing the registers of the one that stays, we'd be accessing the wrong .reg section. --=20 Pedro Alves