From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116210 invoked by alias); 12 Feb 2018 14:54:38 -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 115693 invoked by uid 89); 12 Feb 2018 14:54:37 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f180.google.com Received: from mail-qt0-f180.google.com (HELO mail-qt0-f180.google.com) (209.85.216.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Feb 2018 14:54:36 +0000 Received: by mail-qt0-f180.google.com with SMTP id g14so19168684qti.2 for ; Mon, 12 Feb 2018 06:54:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s2FvS1hFGdHxGC4Z4/DeuGTDJ89E/1wauFKG6KNnoMo=; b=sg6qrZgvUVhzDYnJ39hk6Ejitwl7VmpTDFfpQUHyhNaGHtj2qOq/d33SVHqGcfwOUG juGdsY8tUS0y0zexoUC3a7mBsJWOWIIzpXq5K2gtYVXLkGGJs1z4CgAhINRbld3VSOiG /sVkC0Z++gHsP7PhFAjb/r2gnEt6VTw1KncGScocN75naSMjma15ooxeD7YImHgwuSma sPtyHjeBHFvpxf+RvY8AviVGkyn48VRIFCiIvz5N8MFaUIKX6No3/Aa9kUmlXF74uF4B TvbOsNJ+H5M3l1xFTvpdSYuCeH8h00l+19EyD4VAPNP0h0RaxhAGWPyBBcb+wcfFx7lE g6FQ== X-Gm-Message-State: APf1xPBEuIUVOcwalhX964OF9hHqyr+Lpg2pRWz9dO0GvxDvs/TOYQEn pGdfdyCgLVLAB9JvVok77DrlJRr4kYhv08IqemM= X-Google-Smtp-Source: AH8x224iLekGWF251DEHFhD/nQEFfbGoyN94BbJnJzWekuhejkB/HJnwKZFgIKtwme+8XOeNi0A5RWpB74NSGCOTrxM= X-Received: by 10.237.38.101 with SMTP id z92mr18919272qtc.62.1518447274803; Mon, 12 Feb 2018 06:54:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.153.232 with HTTP; Mon, 12 Feb 2018 06:54:34 -0800 (PST) In-Reply-To: References: <780169f5-fa63-3357-ed78-a3045991c307@nvidia.com> From: Yao Qi Date: Mon, 12 Feb 2018 14:54:00 -0000 Message-ID: Subject: Re: Printing thread_local a.k.a. __thread variables To: Dmitry Antipov Cc: GDB Development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00085.txt.bz2 On Mon, Feb 12, 2018 at 2:15 PM, Dmitry Antipov wrote: > On 02/12/2018 05:02 PM, Yao Qi wrote: > >> Because you are in thread 1, main thread, in which tlocal is not changed. >> If you switch to other threads, you'll see the right value of tlocal. > > Argh. But this seems doesn't work for extended-remote target: > What is "this"? Can you be more explicit and precise? .... > (gdb) thread apply all print tlocal > > Thread 9 (Thread 10463.10471): > Cannot find thread-local storage for Thread 10463.10471, executable file > target:/tmp/t-thread: > Remote target failed to process qGetTLSAddr request ... is it broken in every threads in "thread apply all" or just in some threads? Can you reproduce it every time or it is intermittent? If you manually switch threads via command "thread N", can you examine 'tlocal'? I remember that there may be a race that GDB is already aware of a thread, but libthread_db still isn't. > > (gdbserver side with '--remote-debug' agrees with the above): > > getpkt ("qGetTLSAddr:p28df.28e7,0,7f963e8a7330"); [no ack sent] > putpkt ("$E01#a6"); [noack mode] > > Is my gdbserver is mis(configured|compiled) and do something wrong with > libthread_db? > If GDBserver can get TLS address for some threads, but failed for others, GDBserver must be configured/compiled correctly. --=20 Yao (=E9=BD=90=E5=B0=A7)