From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99455 invoked by alias); 6 Sep 2017 13:05:27 -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 99413 invoked by uid 89); 6 Sep 2017 13:05:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2489, our X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailbackend.panix.com Received: from mailbackend.panix.com (HELO mailbackend.panix.com) (166.84.1.89) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Sep 2017 13:05:25 +0000 Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mailbackend.panix.com (Postfix) with ESMTPSA id E300C116B0; Wed, 6 Sep 2017 09:05:23 -0400 (EDT) Received: by mail-oi0-f49.google.com with SMTP id n18so41095812oig.2; Wed, 06 Sep 2017 06:05:23 -0700 (PDT) X-Gm-Message-State: AHPjjUhgrw8G2U76zDN3XfA8XZSkFpUFl2sYn8dHilhKbE8yqDVIgL08 cgNi+drMgT7aXCCvNuzjsFvj+q7bCw== X-Google-Smtp-Source: ADKCNb6ht5jv8afnuuBJetlY2mCIcqt2mKNNXYO4uUIuawfmqDJRMCVL6RpArC2aeA6OT76xmVAtUPLAjAfLf/u1/zw= X-Received: by 10.202.81.200 with SMTP id f191mr2774149oib.137.1504703122763; Wed, 06 Sep 2017 06:05:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.40.98 with HTTP; Wed, 6 Sep 2017 06:05:22 -0700 (PDT) In-Reply-To: <4ed368f7-4469-4a49-c4e3-0c3afc18c121@redhat.com> 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> <4ed368f7-4469-4a49-c4e3-0c3afc18c121@redhat.com> From: Zack Weinberg Date: Wed, 06 Sep 2017 13:05:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/3] Pretty-printing for errno To: Pedro Alves Cc: GNU C Library , gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-09/txt/msg00007.txt.bz2 On Tue, Sep 5, 2017 at 6:31 PM, Pedro Alves wrote: > On 09/05/2017 10:15 PM, Zack Weinberg wrote: >> >> 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? That is correct. > 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. I am not familiar with the glibc-side TLS implementation, nor with libthread_db.so, nor the code in GDB that uses libthread_db.so. However, reading the implementation of td_thr_tls_get_addr leads me to believe that that function is *supposed* to work even if libpthread.so has not been loaded into the 'inferior'. If it doesn't, perhaps that is a bug on our side. Do you know if GDB even tries? It's not obvious to me looking at linux-thread-db.c. > 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. Again, is it possible to do (the equivalent of) this from the initialization code of a pretty-printer module? Specifically, there already exists a Python function that's doing this: def register(objfile): """Register pretty printers for the current objfile.""" printer = gdb.printing.RegexpCollectionPrettyPrinter("glibc-errno") printer.add_printer('error_t', r'^(?:__)?error_t', ErrnoPrinter) if objfile == None: objfile = gdb gdb.printing.register_pretty_printer(objfile, printer) called when the module is loaded; what would I need to add to that so that the macro is defined (if it isn't already)? zw