From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id E33FC3857C73 for ; Sun, 27 Jun 2021 22:26:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E33FC3857C73 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-419-5dlP2vHoNg6yz1xeNj9Zvg-1; Sun, 27 Jun 2021 18:25:59 -0400 X-MC-Unique: 5dlP2vHoNg6yz1xeNj9Zvg-1 Received: by mail-qv1-f69.google.com with SMTP id cj11-20020a056214056bb029026a99960c7aso15958697qvb.22 for ; Sun, 27 Jun 2021 15:25:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=+61E6HNwZUGwmYLgjPJgNk4l5V5xduGWgPK0gOsh9lI=; b=kMHA419GKiV2wRX08Ky/wjnarTY8DhNiikLpNHqTvQhBB266KkVBqIIN/pWb111T/n WE6caYoRs+66kJR8rW4JJvrDvlKppBuLVEIzHfb69xEyTUsbpZeLWrR+Vz2v5y5d2RGO +aKNVZvVxBWWpv7jddDqj96sIm+DUoq/+VG/GEoNt64U4S+SkfR8CfwUtD/ImPea4TaV zvJE9DXZhQiLxIB64ORz5JDEbq93MJmvbYViVn1y/DuMxoIWao3SIPCvGM1SfgfvMjnZ xqpfj00UXXLT/1HMiIUjMkoejzr6sUhq+cfotcgJozvMfLjeV1y22dsBSWBc/aM7ZXI1 hksA== X-Gm-Message-State: AOAM530OwgEx/XEjHoginbgLpnsv4zB8hjFUSTGDeC6qs6n+hNPhaSe4 lHc+bR1LAEiIOS4yLarWXRkhet3GCXfbguAQ860182H0m1JDSCMk0QTWX74PDAgqBbmLf3bfdgG QRoebRtZaX8hHFI38IpG9mksDEu5vg7Jr8t9J+vLyLCYVdYJbvVd0M+R6TazW X-Received: by 2002:ac8:7b2e:: with SMTP id l14mr5374066qtu.222.1624832758507; Sun, 27 Jun 2021 15:25:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxh4sep5ftGvwLbJm+3BunyfVRLW+4t3WeI4suDsmY0ru1khMTVoia9DhFNVolcxa5/WTqgLA== X-Received: by 2002:ac8:7b2e:: with SMTP id l14mr5374048qtu.222.1624832758219; Sun, 27 Jun 2021 15:25:58 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id s19sm996198qks.77.2021.06.27.15.25.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Jun 2021 15:25:57 -0700 (PDT) Subject: Re: [PATCH] nptl: Export libthread_db-used symbols under GLIBC_PRIVATE To: Simon Marchi , Florian Weimer , libc-alpha@sourceware.org Cc: gdb@sourceware.org References: <877disuwfq.fsf@oldenburg.str.redhat.com> <4df1e03a-eead-82b2-289f-b6cb7ddc0159@polymtl.ca> From: Carlos O'Donell Organization: Red Hat Message-ID: <26256d31-616d-2fc7-7788-937776287791@redhat.com> Date: Sun, 27 Jun 2021 18:25:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <4df1e03a-eead-82b2-289f-b6cb7ddc0159@polymtl.ca> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jun 2021 22:26:03 -0000 On 6/20/21 8:38 AM, Simon Marchi via Libc-alpha wrote: > On 2021-06-17 3:23 p.m., Florian Weimer via Gdb wrote: >> Kevin, this *almost* gives us the perfect debugging experience with your >> patched GDB in Fedora 35, according to my preliminary tests. A build >> with the patch is running here: >> >> >> >> However, it seems that GDB still needs pthread_create in the .symtab to >> trigger loading of libpthread_db. A fully stripped libc.so.6 without >> .symtab does not trigger loading in my experiments. (The other symbols >> we preserve for valgrind's sake and are immaterial to GDB.) In other >> words, > > Stupid question, but: since pthread_create is a function exposed by the > libc.so shared library, won't there still be an entry for it in .dynsym? No question is stupid. Thank you for asking. Yes, there *must* be a .dynsym entry for pthread_create in libc.so.6 in order for the dynamic loader to bind the reference to the definition. > And if so, shouldn't GDB see it? It should. Today gdb is only using the internal lookup_minimal_symbol() API in order to trigger libthread_db loading, and it's not clear to me if that will load *all* of the dynamic symbols during gdb startup. Someone would need to debug the minsyms.c API to see if something isn't working as expected. gdb/minsyms.c: 1267 When files contain multiple sources of symbol information, it is 1268 possible for the minimal symbol table to contain many duplicate entries. 1269 As an example, SVR4 systems use ELF formatted object files, which 1270 usually contain at least two different types of symbol tables (a 1271 standard ELF one and a smaller dynamic linking table), as well as 1272 DWARF debugging information for files compiled with -g. So it sounds like the data is loadable, and mergeable, but it appears that it's not all there at early startup in gdb. -- Cheers, Carlos.