From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18514 invoked by alias); 6 Sep 2017 21:03:14 -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 17805 invoked by uid 89); 6 Sep 2017 21:03:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=HX-HELO:sk:mailbac, H*RU:sk:mailbac, prominent, Hx-spam-relays-external:sk:mailbac 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 21:03:08 +0000 Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by mailbackend.panix.com (Postfix) with ESMTPSA id 3B92711125; Wed, 6 Sep 2017 17:03:06 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id r20so19696281oie.0; Wed, 06 Sep 2017 14:03:06 -0700 (PDT) X-Gm-Message-State: AHPjjUhHulECJr+l50dPdhVFa7lNWApmFaprYqCvlTtv8r/jX2EsymSw fAVFlk8+VgEobgEw03t+/69gD4WcHw== X-Google-Smtp-Source: ADKCNb4alsXfB2LEH2ZXjOtAt1uFf6dzXscItTBJyNOOywucDExob3fuISWP58lH971lcPzH23d3OsMNHGnFwclLC+k= X-Received: by 10.202.77.140 with SMTP id a134mr531144oib.155.1504731786265; Wed, 06 Sep 2017 14:03:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.40.98 with HTTP; Wed, 6 Sep 2017 14:03:05 -0700 (PDT) In-Reply-To: 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 21:03: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/msg00011.txt.bz2 On Wed, Sep 6, 2017 at 9:31 AM, Pedro Alves wrote: > On 09/06/2017 02:05 PM, Zack Weinberg wrote: >> 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. > > GDB only tries to load libthread_db.so if it detects libpthread.so loaded > in the inferior. gdb/linux-thread-db.c:thread_db_new_objfile is called for > every shared library found in the inferior. > > However, if we hack gdb like this to force it to always try to > load libthread_db.so: ... > That "td_ta_new failed: application not linked with libthread" > error is output by thread_db_err_str in linux-thread-db.c. It's > just pretty-printing TD_NOLIBTHREAD. I.e., opening a connection > to libthread_db.so fails: > > /* Now attempt to open a connection to the thread library. */ > err = info->td_ta_new_p (&info->proc_handle, &info->thread_agent); > if (err != TD_OK) > { > > Because lithread_db.so itself "rejects" the inferior. So, changes to both gdb and libthread_db seem to be required here. I do think that _in principle_ it ought to be possible to use libthread_db to retrieve the address of thread-local data even if the inferior is not linked with libpthread; glibc has quite a few thread-specific variables (errno most prominent, of course, but also h_errno, _res, etc), and so might any library which can be used from both single- and multithreaded programs. This is really not code I feel comfortable hacking up, though, and it's probably more of a project than I have time for, in any case. ... >> 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)? > > I'm hoping that other people more experienced with the gdb > Python API can chime in. My idea was just to call > gdb.execute ("macro define errno (*(int *) __errno_location ())") > somewhere around your Python code. I'll tinker with that. Thanks. zw