* Szabolcs Nagy: > The 05/20/2020 09:02, Florian Weimer via Gcc wrote: >> * Richard Henderson: >> > On 5/19/20 3:38 AM, Florian Weimer via Gcc wrote: >> >> One minor improvement would be to document __aarch64_have_lse_atomics as >> >> interposable on the GCC side and define that directly in glibc, so that >> >> lse-init.o is not linked in anymore and __aarch64_have_lse_atomics can >> >> be initialized as soon as ld.so has the hwcap information. >> > >> > The __aarch64_have_lse_atomics symbol is not interposable. >> > We use a direct pc-relative reference to it from each lse thunk. >> >> What I meant that users are allowed to supply their own definition in a >> static link. Sorry, not sure what the correct terminology is here. I >> don't think any code changes would be needed for that, it's just a >> matter of documentation (and being careful about future evolution of the >> code). > > are you proposing to put it in libc_nonshared.a/crt1.o? > (and then ld.so would treat it specially when loading a > module to initialize it early)
No, just to put a definition of __aarch64_have_lse_atomics into ld.so, and initialize that along with AT_HWCAP parsing. It avoids pulling a definition of __getauxval into the dynamic loader and creating the initarray section. I haven't checked whether any of the outline atomics are actually used durign startup. It's _dl_mcount and something in the guts of the internal dlsym implementation (probably the gscope lock, but that code path would not be taken during startup). > or only dealing with it in libc.so, and let other modules > still initialize it late (in case there are higher prio > ctors or ifunc resolvers using atomics)? By itself, I don't think doing this in libc or libpthread is worth it. But once we have the mechanism for ld.so, we could apply it here as well. Thanks, Florian