AArch64 and -moutline-atomics

AArch64 and -moutline-atomics

[Florian Weimer via Libc-alpha]

FYI: I've verified that when building with GCC 10, outline atomics are
correctly initialized on LSE machines.  The ld.so ELF constructors
eventually get run and initialize __aarch64_have_lse_atomics.

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.

Thanks,
Florian

Re: AArch64 and -moutline-atomics

[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.

Anything that is done to alter that affects the abi of every shared object that
uses the thunks.  Which makes it pretty much a non-starter as a deployment option.


r~

Re: AArch64 and -moutline-atomics

[Florian Weimer via Libc-alpha]

* 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).

Thanks,
Florian

Re: AArch64 and -moutline-atomics

[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)

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)?

Re: AArch64 and -moutline-atomics

[Florian Weimer via Libc-alpha]

* 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