[PATCH] libdwfl: Do not dlopen libdebuginfod if DEBUGINFOD_URLS is unset or empty

Mark Wielaard mark@klomp.org
Wed Dec 9 16:42:01 GMT 2020

On Wed, 2020-12-09 at 18:35 +0300, Dmitry V. Levin wrote:
> On Mon, Nov 09, 2020 at 09:57:57AM -0500, Frank Ch. Eigler via Elfutils-devel wrote:
> > > [...] The problem with doing the dlopen late is that we also need
> > > libcurl and initializing libcurl (as done by libdebuginfod) is not
> > > thread-safe.
> > 
> > From reading libcurl code, and that of other clients, I still believe
> > this concern was & is overrated.  We could back down to simple
> > debuginfod_begin time mutex-protected curl_global_init calls, and we'd
> > be as fine as other applications.  We could ditch the dlopen /
> > dso-ctor issues entirely.
> Excuse me, has there been any follow-up to this discussion?

Not really. The issue is that the documentation of curl_global_init has
this very scary warning: "This function is not thread safe. You must
not call it when any other thread in the program (i.e. a thread sharing
the same memory) is running. This doesn't just mean no other thread
that is using libcurl." https://curl.se/libcurl/c/curl_global_init.html

So we try to make sure curl_global_init is called as soon as possible
by putting the call in the libdebuginfod.so libdebuginfod_ctor and
libdw has a __libdwfl_debuginfod_init ctor which tries to do the dlopen
of libdebuginfod as early as possible. Using ctors here is done so that
we hopefully call curl_global_init before any threads are started.
Frank might be right that all this is just super paranoia. But given
that the libcurl developers put that scary warning in their
documentation for now I am assuming we have to be that paranoid. I
haven't asked them if they believe that comment is still current



More information about the Elfutils-devel mailing list