From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 4BFC53893642; Fri, 16 Apr 2021 16:08:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4BFC53893642 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 13GG7sLh009148 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Apr 2021 12:07:59 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13GG7sLh009148 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3B6A61E813; Fri, 16 Apr 2021 12:07:54 -0400 (EDT) Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744) To: Florian Weimer , libc-alpha@sourceware.org, gdb-patches@sourceware.org Cc: Emil Velikov , Kevin Buettner , Pedro Alves References: <87sg3qnrz3.fsf@oldenburg.str.redhat.com> From: Simon Marchi Message-ID: <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> Date: Fri, 16 Apr 2021 12:07:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <87sg3qnrz3.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 16 Apr 2021 16:07:54 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 16:08:03 -0000 On 2021-04-16 11:56 a.m., Florian Weimer wrote: > libthread_db is loaded once GDB encounters libpthread, and at this > point, ld.so may not have been loaded yet. Hi Florian, Can this state (libpthread loaded, ld.so not loaded) really happen during the normal lifetime of a process? My understanding is that this state happens when attaching only because GDB reads the shared libraries from the process in an undefined order, so libpthread may be discovered before ld.so. So we present to libthread_db a state that doesn't really make sense. Still, that quick fix probably helps in the attach case, since it avoids requiring symbols outside of libpthread, but I would just like to understand. Simon