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,module_info,module_address_section,
> get_debuginfod_client,...`,
> `dwarf_{tag,getscopes_die,formstring,fromudata,diename,getsrc_die,dieoffset,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.
> 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.
Aaron
