AArch64 and -moutline-atomics

[Florian Weimer]

* 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