From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 4DB073857C50 for ; Thu, 31 Mar 2022 12:10:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DB073857C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id C5B45304319C; Thu, 31 Mar 2022 14:10:10 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 0B2FC413CD0E; Thu, 31 Mar 2022 14:10:10 +0200 (CEST) Message-ID: Subject: Re: [PATCH] Avoid dlopen on debuginfod-client when not configured From: Mark Wielaard To: Dirk =?ISO-8859-1?Q?M=FCller?= Cc: elfutils-devel@sourceware.org Date: Thu, 31 Mar 2022 14:10:09 +0200 In-Reply-To: References: <20220328213641.8667-1-dirk@dmllr.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2022 12:10:14 -0000 Hi Dirk, On Tue, 2022-03-29 at 13:06 +0200, Dirk M=C3=BCller wrote: > Am Di., 29. M=C3=A4rz 2022 um 09:42 Uhr schrieb Mark Wielaard < > mark@klomp.org>: > > The patch itself looks right. But I am slightly afraid this > > (theoretically?) will break some programs which set DEBUGINFOD_URLS > > themselves. We currently have no other way to make libdwfl use > > debuginfod-client. Thoughts? >=20 > I was concerned about that as well, but I couldn't google a case where > this is the case. What we can also do is to do the initialization > lazily upon first use rather than in a > constructor function, but the intention of initializing early has been > specified as avoiding issues in multiple threads with libcurl: >=20 > commit fa0226a78a101d26fd80c7e9e70a5f0aa6f9d1cc > Author: Mark Wielaard > Date: Sun Nov 17 22:17:26 2019 +0100 >=20 > debuginfod: add client context >=20 > Add a mandatory debuginfod_begin()/_end() call pair to manage a client > object that represents persistent but non-global state. From libdwfl, > dlopen the debuginfod.so client library early on. This hopefully > makes sure that the code (and the libcurl.so dependency) is loaded > before the program goes into multi-threaded mode. >=20 >=20 > What we can do is both, do the reinit at a later point in time if the > environment variable happens to be set at that point in time. then you > are risking the thread-safety issues only when there is no other way. >=20 > Or just do it lazily on demand, and work through the libcurl or > whatever the unsafety issue is. This is indeed the (safety) issue I am concerned about. I just sent an email to the libcurl mailinglist (CCed to the elfutils-devel list) to ask about how/when/if a library should call curl_global_init. https://curl.se/mail/lib-2022-03/0118.html Lets see what the curl developers say and then decide what to do. Cheers, Mark