From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2132 invoked by alias); 10 Jul 2017 18:21:32 -0000 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 Received: (qmail 2121 invoked by uid 89); 10 Jul 2017 18:21:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Jul 2017 18:21:31 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E651CC04F4DF; Mon, 10 Jul 2017 18:21:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E651CC04F4DF Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E651CC04F4DF Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3986417174; Mon, 10 Jul 2017 18:21:28 +0000 (UTC) Subject: Re: gdb / thread_db / multiple ABI question To: sellcey@cavium.com, gdb@sourceware.org References: <201707071820.v67IKXSr017199@sellcey-dt.caveonetworks.com> <306e2da9-4fea-76a2-e130-f6661f9826e8@redhat.com> <1499459428.13519.35.camel@cavium.com> <1f97046b-2ffd-b4ac-6626-412b75a54dd5@redhat.com> <1499709771.13519.43.camel@cavium.com> From: Pedro Alves Message-ID: Date: Mon, 10 Jul 2017 18:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1499709771.13519.43.camel@cavium.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-07/txt/msg00013.txt.bz2 On 07/10/2017 07:02 PM, Steve Ellcey wrote: > No, without thread_db I get this: > > (gdb) file m32 > Reading symbols from m32...done. > (gdb) core c_32 > [New LWP 79425] > [New LWP 79425] > [New LWP 79425] This means that GDB/bfd thinks that there are 3 threads in the core, but they all have the same TID, which is of course bogus. So this still looks to me like something is wrong on the bfd side. Try "objdump -h c_32". You should see one ".reg/NNN" section per thread, like e.g.: $ objdump -h core.1904 | grep "reg/" 1 .reg/1904 000000d8 0000000000000000 0000000000000000 000006a0 2**2 9 .reg/1909 000000d8 0000000000000000 0000000000000000 00000e00 2**2 13 .reg/1910 000000d8 0000000000000000 0000000000000000 00001560 2**2 Put a breakpoint on elf.c:elfcore_grok_note, and step through it, checking that the proper NT_PRSTATUS / NT_PSINFO hooks get called via the elf_backend_data vector, and check that they're extracting the right fields/offsets out of the core structures. Once you get 3 threads without libthread_db., then this: > (gdb) info threads Found 0 new threads in iteration 0. > Id Target Id Frame > * 3 Thread 0xf739ef70 (LWP 8660) 0x00400680 in doSomeThing () > 4 Thread 0xf69bf490 (LWP 8662) warning: Couldn't find general-purpose registers in core file. > PC register is not available should not longer happen. The above with libthread_db is very likely happening because libthread_db found a thread that maps to LWP 8662 in libpthread's internal data structures, but then GDB/bfd can't find the ".reg/8662" note/section in the core dump. Thanks, Pedro Alves