From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64083 invoked by alias); 5 Sep 2017 22:32:25 -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 55808 invoked by uid 89); 5 Sep 2017 22:32:12 -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=sight, ordinary, awareness 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; Tue, 05 Sep 2017 22:32:04 +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 341E67539D; Tue, 5 Sep 2017 22:32:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 341E67539D 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 6D9B361F27; Tue, 5 Sep 2017 22:31:56 +0000 (UTC) Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno To: Zack Weinberg References: <20170622224456.1358-1-zackw@panix.com> <3a7946e9-d178-f878-9774-64ff44bcf5df@redhat.com> <9490d183-a57b-b336-3131-6580e4773818@redhat.com> <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> <1d38297f-f430-ca73-6d3f-a67144d08eea@redhat.com> <7348d7d9-b339-b14f-3dea-31d17c996a2a@redhat.com> Cc: Phil Muldoon , GNU C Library , gdb@sourceware.org, Joseph Myers , Florian Weimer , Tom Tromey , Siddhesh Poyarekar From: Pedro Alves Message-ID: <4ed368f7-4469-4a49-c4e3-0c3afc18c121@redhat.com> Date: Tue, 05 Sep 2017 22:32: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-09/txt/msg00006.txt.bz2 On 09/05/2017 10:15 PM, Zack Weinberg wrote: > On Mon, Sep 4, 2017 at 5:25 PM, Pedro Alves wrote: >> >> FYI, this is now all in gdb master. I believe all the gdb issues >> uncovered by the errno printer have been addressed. Let me know >> if you're aware of something still not working properly. > > I'm sorry I never got around to experimenting with your patches before now. Really no worries. > With gdb master as of earlier today, and my patched glibc that tries > to pretty-print errno, I can confirm that nearly everything works as > desired. `p (error_t) 0` invokes the pretty-printer, and when > preprocessor macro bodies are available to the debugger (-ggdb3) so > does `p errno`. Unfortunately I am still getting this error message > when I try to print the underlying thread-local errno variable (which > is what `p errno` does if macro bodies are not available): > > Cannot find thread-local storage for process 4367, executable file > /home/zack/projects/glibc/glibc-build/stdlib/test-errno-printer: > Cannot find thread-local variables on this target > > I don't understand why thread-local variables are inaccessible on my > perfectly ordinary x86_64-unknown-linux-gnu workstation (the base OS > is Debian 'stretch'). Do you have any idea what might be wrong? I assume your test program isn't actually linked with -pthread? When you do "print errno" in this situation, because there's no "#define errno ..." in sight, gdb ends up finding the real "errno" symbol, which, even though the program isn't threaded, is a TLS symbol, and as such has a DWARF location expression describing its location as an offset into the thread-local block for the current thread. GDB needs to resolve that address, and for threaded programs that is normally done with assistance from libthread_db.so. The problem is then that libthread_db.so only works with programs that link with libpthread.so, and if your test program is actually non-threaded, it doesn't link with libpthread.so, So without libthread_db.so's assistance, gdb cannot "find [the address of] thread-local variables on this target". The error message is coming from generic GDB "get address of tls var" code several layers above GNU/Linux-specific libthread_db.so-interaction code, but still it could probably be made clearer, maybe by adding "the address of". A workaround specifically for errno, and only for live-process debugging [*] is the "macro define" trick I had suggested before: (gdb) macro define errno (*__errno_location ()) After that, "p errno" ends up calling __errno_location just like when you compile the test program with -g3. [*] doesn't work with core file / postmortem debugging. I don't know whether GDB could be able to resolve the location of the errno variable for the main thread (for single-threaded programs): - without libthread_db.so assistance and - without baking in awareness of glibc internal data structures If there is I'd absolutely love to learn about it. Thanks, Pedro Alves