Hi Mark,

Am Di., 29. März 2022 um 09:42 Uhr schrieb Mark Wielaard <m...@klomp.org>:

> I assume this is because debuginfod-client loads and initializes
> libcurl, which triggers crypto checks for https support?

Yes, the dependencies of the DSO contain libcurl and other libraries
including the openssl library, which, when patched with FIPS support,
take quite a while to initialize.

> 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?

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:

commit fa0226a78a101d26fd80c7e9e70a5f0aa6f9d1cc
Author: Mark Wielaard <m...@klomp.org>
Date:   Sun Nov 17 22:17:26 2019 +0100

   debuginfod: add client context

   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.


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.

Or just do it lazily on demand, and work through the libcurl or
whatever the unsafety issue is.

Greetings,
Dirk

Reply via email to