From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aUWQJBT72GBfewAAWB0awg (envelope-from ) for ; Sun, 27 Jun 2021 18:26:28 -0400 Received: by simark.ca (Postfix, from userid 112) id 86A981F1F2; Sun, 27 Jun 2021 18:26:28 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 495681E01F for ; Sun, 27 Jun 2021 18:26:27 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CC6B7383D025 for ; Sun, 27 Jun 2021 22:26:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CC6B7383D025 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1624832786; bh=+61E6HNwZUGwmYLgjPJgNk4l5V5xduGWgPK0gOsh9lI=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=syROhqD6ey1bIjSGMvsD00JBf4bV6pR8Rv91tVH6G8ynZbmHKyBQzXH9PAiKB4Xpe CmId4rkcsnintxMMfZ4rpkjk+vSPT0Pph83QCBftqGTSfMdFWMqQn7D1oeCnPa5uW2 sYH/GNeYcvnVFfJgVIBofMEwTX5hHFYt7HHx5Me0= 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 References: <877disuwfq.fsf@oldenburg.str.redhat.com> <4df1e03a-eead-82b2-289f-b6cb7ddc0159@polymtl.ca> 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-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: , From: Carlos O'Donell via Gdb Reply-To: Carlos O'Donell Cc: gdb@sourceware.org Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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.