From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53105 invoked by alias); 27 Oct 2017 15:00:36 -0000 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 Received: (qmail 52988 invoked by uid 89); 27 Oct 2017 15:00:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients 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; Fri, 27 Oct 2017 15:00:29 +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 D14B85F73C; Fri, 27 Oct 2017 15:00:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D14B85F73C Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com 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 628C280DF1; Fri, 27 Oct 2017 15:00:15 +0000 (UTC) Subject: Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file To: "Maciej W. Rozycki" , Djordje Todorovic References: <74618d56-fa31-4cfe-329f-6a9078bac92b@rt-rk.com> <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> Cc: binutils@sourceware.org, gdb-patches@sourceware.org, "nemanja.popov@rt-rk.com" , petar.jovanovic@rt-rk.com, "Ananthakrishna Sowda (asowda)" , Nikola Prica From: Pedro Alves Message-ID: Date: Fri, 27 Oct 2017 15:00: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00853.txt.bz2 On 10/25/2017 11:38 PM, Maciej W. Rozycki wrote: > (gdb) PASS: gdb.threads/tls-core.exp: load generated corefile > p/x foo > Cannot find thread-local storage for LWP 8829, executable file .../gdb/testsuite/outputs/gdb.threads/tls-core/tls-core: > Cannot find thread-local variables on this target > (gdb) FAIL: gdb.threads/tls-core.exp: print thread-local storage variable > > which I am fairly sure that is related (along with the "core file may not > match specified executable file." message) to an attempt to use native > `libthread_db'. The "core file may not match specified executable file." sounds like something else. I think you'll get that if the program name recorded in the core data structure is not the same as the name of the executable. Try setting a breakpoint on core_file_matches_executable_p. > > Pedro, do I remember correctly it was you who recently mentioned (maybe > at the Cauldron) the need to have the issue of using `libthread_db' in > cross-debugging correctly addressed? For the time being I think we want > to KFAIL this test case if [is_remote target] (in its recently cleaned-up > meaning, as the test case actually succeeds with `native-gdbserver') -- > but do we have a tracking bug already? Right, libthread_db is loaded by the host gdb, and that libthread_db is only good for native debugging. Things work with live cross-debugging against gdbserver because in that case it's gdbserver that loads the right libthread_db, not gdb. Thanks, Pedro Alves