On Donnerstag, 18. Juli 2024 17:56:39 MESZ Aaron Merey wrote: > Hi Milian, > > On Thu, Jul 18, 2024 at 6:14 AM Milian Wolff <m...@milianw.de> wrote: > > On Donnerstag, 18. Juli 2024 00:33:59 MESZ Aaron Merey wrote: > > > v1 can be found at > > > https://sourceware.org/pipermail/elfutils-devel/2023q3/006329.html > > > > > > Heather McIntyre is the original author of v1 of these patches. > > > Heather and myself co-wrote v2. > > > > Hey you all, > > > > this sounds very promising! I have some high level questions: > > > > Could you please add some documentation on the thread safety guarantees > > when elfutils was compiled with `--enable-thread-safety`? > > This is definitely needed. I've been working on adding man pages for > elfutils public library functions. We should indicate whether each > function is MT-Safe. We should also have man pages for libelf, libdw, > etc, themselves and these should include thread safety information and > constraints. I will prioritize this. > > > For my purposes in > > maintaining profilers (heaptrack, hotspot), it would be extremely cool if > > we could eventually use multiple threads to analyze separate samples. In > > theory, I would hope that "write" operations (such as > > `dwfl_report_{begin,end,elf}` will require synchronization, but > > subsequent "read" operations (such as those needed for symbolication > > (`dwfl_{addrmodule,module_getsymtab,module_getsym_info,module_nextcu,modul > > e_info,module_address_section, get_debuginfod_client,...`, > > `dwarf_{tag,getscopes_die,formstring,fromudata,diename,getsrc_die,dieoffse > > t,linesrc,lineno,getsrcfiles,attr_integrate,...`) or unwinding > > (`dwfl_{thread_state_registers,frame_pc,getthread_frames}) could happen > > in parallel. Is that the case already after this patch set? > > This patch set is not entirely comprehensive. It focuses on thread safety > in libelf and libdw (not libdwfl) and there is still at least one data race > in libelf (see https://sourceware.org/bugzilla/show_bug.cgi?id=31967). > However what you describe should be possible when this feature is more > fully implemented. > > In the v1 of this patch set there is a patch which removed the > "experimental" notice from the --enable-thread-safety configure option. > I left this patch in v2 but I think that we should defer that patch and > instead keep thread safety "experimental" until it is more fully tested > and production ready.
OK, good to know. If you are looking for feedback once this is further along
and includes libdwfl, then I'm more than happy to play around with it. But I
guess I'll have to wait until libdwfl is thread safe to some degree.
> > Generally it seems like the documentation could see some love in better
> > explaining this feature.
> >
> > How can I query at runtime whether elfutils was compiled with thread
> > safety
> > guarantees or not, such that I can adapt my consumer side accordingly
> > (i.e.
> > enable multi-threading or not)?
>
> libelf is compiled with pthread only when elfutils is built with
> the --enable-thread-safety configure option. So ATM I believe that
> checking the libelf binary for pthread_rwlock_* symbols with
> {eu-}readelf or another tool is your best option.
>
> I should also mention that libdw is built with pthread unconditionally,
> whether or not --enable-thread-safety is given. However libelf and
> libdw should always be installed and upgraded in lockstep, so if
> libelf contains pthread_rwlock_* symbols then it's reasonable to
> assume that libdw was also built with --enable-thread-safety.
>
> However this is not ideal. Maybe we should add some way to verify
> thread safety to the public library API.
Yes please. Looking up `pthread_rwlock_*` symbols in a lib linking against
libdw just to figure out if things are threadsafe or not is super brittle.
Please add an explicit API that forwards the `--enable-thread-safety` compile
time flag such that we can query it at runtime.
thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
