From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id DDBA1385703C; Mon, 29 Mar 2021 08:26:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DDBA1385703C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (port=43227 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lQnEg-0002Uz-AO; Mon, 29 Mar 2021 08:26:58 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1lQnEg-0001bW-7d; Mon, 29 Mar 2021 10:26:58 +0200 From: Florian Weimer To: Cc: Simon Marchi , Simon Marchi via Libc-alpha Subject: Re: [PATCH] nptl: Move stack list variables into _rtld_global References: <87a6vlthqn.fsf@oldenburg2.str.redhat.com> <0f7bf7d7-36f9-ce7f-0390-4b39eeb0fffc@polymtl.ca> <87zgzhbjy0.fsf@oldenburg.str.redhat.com> <87mtvhbhqw.fsf@oldenburg.str.redhat.com> <871rctbf2z.fsf@oldenburg.str.redhat.com> Date: Mon, 29 Mar 2021 10:26:58 +0200 In-Reply-To: <871rctbf2z.fsf@oldenburg.str.redhat.com> (Florian Weimer via Gdb-patches's message of "Fri, 05 Mar 2021 20:00:52 +0100") Message-ID: <87a6qmwejx.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, 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: Mon, 29 Mar 2021 08:27:01 -0000 * Florian Weimer via Gdb-patches: > * Simon Marchi: > >>>> If we have to deal with this, I guess that GDB should now do things in a >>>> different order: go through the whole library list and load their >>>> symbols. And then if one of those libraries were libpthread, try to >>>> initialize libthread_db. >>> >>> Initialization of libthread_db should be unconditional. Programs use >>> TLS data without linking against libpthread. And glibc 2.34 might not >>> have a separate libpthread at all. >> >> Ok, currently GDB attempts to load libthread_db when noticing the main >> objfile / program (I guess it is needed if the program is statically >> linked to libpthread?) or when seeing a library named libpthread*. > > Would it be possible to load libthread_db unconditionally after loading > all shared objects? Then it is loaded only once. > >> About the hypothetical scenario for glibc 2.34: do you mean that the >> pthread infrastructure will directly be in libc.so? If so, our current >> strategy of attempting to load libthread_db only for the main program >> or a libpthread* library will indeed not work. And I suppose that will >> also require trying to load libthread_db on every new shared lib... > > I think one attempt loading is enough, after all shared objects are > available. In both the attaching and starting case, libpthread will be > seen by libthread_db if it is there. I do not think it is necessary to > try loading libpthread_db again for each dlopen. Maybe you could > restrict that to trigger on libpthread, but then dlopen of libpthread > does not really work today. I would appreciate if we could make some progress on this issue. Please let me know if you need glibc test builds or something in that area. Thanks.