Hi Aaron, On Wed, Oct 28, 2026 at 03:32:29PM -0400, Aaron Merey wrote: > On Wed, Oct 28, 2026 at 11:22 AM Mark Wielaard <[email protected]> wrote: > > On Tue, 2026-10-27 at 20:34 -0400, Aaron Merey wrote: > > > Store a Dwfl_Module's ebl field atomically in __libdwfl_module_getebl > > > while holding the associated Dwfl load_lock. > > > > > > Change usage of the ebl field so that before using it's either been > > > atomically read or else it's used after __libdwfl_module_getebl returns > > > DWFL_E_NOERROR. > > > > Why not always use __libdwfl_module_getebl ? > > > > [...] > > > > > diff --git a/libdwfl/dwfl_module_getsym.c b/libdwfl/dwfl_module_getsym.c > > > index 2bb07fd8..4905f019 100644 > > > --- a/libdwfl/dwfl_module_getsym.c > > > +++ b/libdwfl/dwfl_module_getsym.c > > > @@ -124,7 +124,8 @@ __libdwfl_getsym (Dwfl_Module *mod, int ndx, GElf_Sym > > > *sym, GElf_Addr *addr, > > > descriptors). */ > > > > > > char *ident; > > > - GElf_Addr st_value = sym->st_value & ebl_func_addr_mask (mod->ebl); > > > + Ebl *ebl = atomic_load_acquire (&mod->ebl); > > > + GElf_Addr st_value = sym->st_value & ebl_func_addr_mask (ebl); > > > *resolved = false; > > > if (! adjust_st_value && mod->e_type != ET_REL && alloc > > > && (GELF_ST_TYPE (sym->st_info) == STT_FUNC > > > > So why not use __libdwfl_module_getebl here? > > This preserves existing behaviour. If mod->ebl is NULL then the mask > from ebl_func_addr_mask leaves the symbol value unchanged. If we use > __libdwfl_module_getebl then the backend could get initialized early > resulting in a different mask.
But just two lines down we call __libdwfl_module_getebl. So I think it would actually be a bug if the ebl hasn't yet been loaded at this point. Cheers, Mark
