Hi Aaron, On Wed, 2026-09-09 at 20:19 -0400, Aaron Merey wrote: > On Wed, Sep 9, 2026 at 3:57 PM Mark Wielaard <[email protected]> wrote: > > > Where in the code/call path is scns.cnt set? > > Asking this question might show I don't fully grok what is going on. > > scns.cnt is set during elf_begin and can be modified by elf_newscn, > elfNN_newphdr and elf_getscn. elf_begin runs before the relevant elf > descriptor can be used by multiple threads. The THREAD-SAFETY doc > lists elf_newscn and elfNN_newphdr as caller-serialized functions so > they must not run concurrently with elfNN/gelf_getshdr. elf_getscn > uses atomics to avoid races between stores and loads (added in the > previous patch in this series). There is one non-atomic load of cnt in > elf_getscn with elf->lock wrlock held but there is no store to cnt > that can occur concurrently (either the store happens in a > caller-serialized function or when elf->lock wrlock is held or in > elf_begin when the descriptor hasn't yet been shared across threads).
Thanks. Phew. So there are really two things being checked. Whether there are any shdrs, which is the state scns.cnt field being > 0. Which is important because section header zero is used to store some state (specifically if number of sections or program headers is larger than fits in the Elf header). Then there is is a check whether the section headers are loaded, which is done by checking either whether state scns.data[0].shdr or the actual scn.data[scnnum].shdr != NULL. Since they are either all loaded or not checking for scns.data[0].shdr != NULL is often sufficient (except if you are interested in a specific shdr. I think I get it now. Thanks for the explanation. Cheers, Mark
