Hi Aaron, On Mon, 2026-08-24 at 23:34 -0400, Aaron Merey wrote: > Document the user thread safety model for elfutils libraries when built > with --enable-thread-safety. > > Signed-off-by: Aaron Merey <[email protected]> > --- > > v2 changes: > Added THREAD-SAFETY to Makefile.am and config/elfutils.spec.in.
Good, added to Makefile.am and %doc. > Mentioned _ELFUTILS_THREAD_SAFE. Good. As the second sentence :) > Distinguished library interfaces (elf_*, dwarf_*, etc.) from libdw.so > and libelf.so. Ack. dwfl_* still TBD. > Clarified that debuginfod_client handles are not tied to the creating > thread. Nicely formulated. > Added example use cases for a phased approach that avoids caller-side > locking as well as what to do if caller side locking is needed. I like this new paragraph. > Clarified that ancestor handles do not need to be re-derived when > modifying derived handles. Ack. > > On Thu, 2026-07-02 at 18:32 -0400, Aaron Merey wrote: > > > +The following libelf and libdw public library functions are > > > caller-serialized. > > > +All other functions in these libraries are thread-safe. > > > + > > > + libelf elf32_checksum, elf32_newehdr, elf32_newphdr, elf32_xlatetof, > > > + elf32_xlatetom, elf64_checksum, elf64_newehdr, elf64_newphdr, > > > + elf64_xlatetof, elf64_xlatetom, elf_begin (non-NULL ref), > > > + elf_cntl, elf_compress, elf_compress_gnu, elf_end, elf_fill, > > > + elf_flagdata, elf_flagehdr, elf_flagelf, elf_flagphdr, > > > + elf_flagscn, elf_flagshdr, elf_newdata, elf_newscn, elf_next, > > > + elf_rand, elf_update > > > + > > > + gelf gelf_checksum, gelf_newehdr, gelf_newphdr, gelf_update_*, > > > + gelf_xlatetof, gelf_xlatetom > > > + > > > + libdw dwarf_begin_elf, dwarf_cfi_end, dwarf_end, > > > dwarf_new_oom_handler, > > > + dwarf_setalt > > > > This looks right, but I don't really know how to verify. > > I plan on using AI-generated tests to try and validate all this. The tests > will not be included in elfutils patches/contributions but they will be > made publicly available. Given how LLMs tend to halucinate what you want to hear I am not sure that really is a solid validation. But I don't know of a static analyzer tool that does this. So it might be better than nothing. > > Have to think hard what it means that Elf and Dwarf are cyclic, but > > apart from that this hierarchy makes sense. > > I don't believe the Elf/Dwarf relationship is cyclic in a way that threatens > this model. dwarf_getelf returns an Elf handle from a Dwarf but the Elf > handle is identical to the one used to create the Dwarf. It does not > create a brand new handle. Ah, right. Thanks. I like this version. Thanks, Mark
