From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30593 invoked by alias); 26 Aug 2015 18:23:23 -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 30426 invoked by uid 89); 26 Aug 2015 18:23:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 26 Aug 2015 18:23:22 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 142DAA2C26; Wed, 26 Aug 2015 18:23:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7QINJ2k025325; Wed, 26 Aug 2015 14:23:20 -0400 Message-ID: <55DE0417.4090309@redhat.com> Date: Wed, 26 Aug 2015 18:23:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ulrich Weigand CC: gdb-patches@sourceware.org Subject: Re: Cell multi-arch broken (Re: [PATCH 2/2] GNU/Linux: Stop using libthread_db/td_ta_thr_iter) References: <20150826173903.3ADD439FA@oc7340732750.ibm.com> In-Reply-To: <20150826173903.3ADD439FA@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00761.txt.bz2 On 08/26/2015 06:39 PM, Ulrich Weigand wrote: > In fact, it is so broken that the test suite assumes we're not even > on a Cell/B.E. (since it can't debug the trivial test program), and > silently skips all Cell tests, so I didn't notice in the daily build > reports ... (Sounds like the testsuite could be improved to better detect this.) > > The reason why we're running into the abort is that the multi-arch > debugging logic attempts to resolve a thread-local variable from > inside the frame unwinders (which is probably not done elsewhere). > This uncovers a code path where the above assertion is wrong: Curious. Could you point me at this code path? I can't seem to find it. I wonder whether can trigger this assertion by stopping the inferior before thread_db is initialized (e.g., entry point), and then trying to print a tls variable? (In order to construct a test case). > > In thread_db_get_thread_local_address, we have: > > /* If we have not discovered any threads yet, check now. */ > if (!have_threads (ptid)) > thread_db_find_new_threads_1 (ptid); > > Now, note that thread_db_get_thread_local_address is one of the few > remaining routines that always uses the thread DB, even if we do > not use thread events. However, thread_db_find_new_threads_1 now > assumes it gets only ever called when using thread events, which > ultimately leads to the assert. > > As a quick fix, the patch appended below makes it work again; > but this may be a bit overkill since thread_db_update_thread_list > no longer realized that we're only interested in process ptid, > and updates all inferiors. (Maybe the to_update_thread_list > target callback should get a ptid argument?) > > Any suggestions on how best to fix this? Try doing it like gdbserver's thread_db_get_tls_address. ... lwp = get_thread_lwp (thread); if (!lwp->thread_known) find_one_thread (thread->entry.id); ... That is, here what we're really after is the td_thrhandle_t of the current thread, in order to be able to call td_thr_tls_get_addr. There's no need to walk thread_db's thread list to find that for a single thread. find_one_thread makes use of td_ta_map_lwp2thr for the mapping we're after. On the GDB side, the equivalent is linux-thread-db.c:thread_from_lwp. Thanks, Pedro Alves