Re: [PATCH] c++, TLS: Support cross-tu static initialization for targets without alias support [PR106435].

[Jason Merrill <jason@redhat.com>]

On 1/4/23 10:30, Iain Sandoe wrote:
> 
> 
>> On 4 Jan 2023, at 15:03, Jason Merrill <jason@redhat.com> wrote:
>>
>> On 1/3/23 18:17, Iain Sandoe wrote:
>>>> On 3 Jan 2023, at 22:22, Jason Merrill <jason@redhat.com> wrote:
>>>>
>>>> On 12/7/22 10:39, Iain Sandoe wrote:
>>>>>   This has been tested on x86_64 and arm64 Darwin and on x86_64 linux gnu.
>>>>>   The basic patch is live in the homebrew macOS support and so has had quite
>>>>>   wide coverage on non-trivial codebases.
>>>>>     OK for master?
>>>>>   Iain
>>>>>     Since this actually fixes wrong code, I wonder if we should also consider
>>>>>   back-porting.
>>>>>     --- >8 ---
>>>>> The description below relates to the code path when TARGET_SUPPORTS_ALIASES is
>>>>> false; current operation is maintained for targets with alias support and any
>>>>> new support code should be DCEd in that case.
>>>>> --
>>>>> Currently, cross-tu static initialisation is not supported for targets without
>>>>> alias support.
>>>>> The patch adds support by building a shim function in place of the alias for
>>>>> these targets; the shim simply calls the generic initialiser.  Although this is
>>>>> slightly less efficient than the alias, in practice (for targets that allow
>>>>> sibcalls) the penalty is a single jump when code is optimised.
>>>>>  From the perspective of a TU referencing an extern TLS variable, there is no
>>>>> way to determine if it requires a guarded dynamic init.  So, in the referencing
>>>>> TU, we build a weak reference to the potential init and check at runtime if the
>>>>> init is present before calling it.  This strategy is fine for targets that have
>>>>> ELF semantics, but fails at link time for Mach-O (which does not permit the
>>>>> reference to be undefined in the static link).
>>>>> The actual initialiser call is contained in a wrapper function, and to resolve
>>>>> the Mach-O linker issue, in the TU that is referencing the var, we now generate
>>>>> both the wrapper _and_ a weak definition of a dummy init function.  In the case
>>>>> that there _is_ a dynamic init (in a different TU), that version will be non-weak
>>>>> and will be override the weak dummy one.
>>>>
>>>> IIUC, this isn't reliable in general; in specific, I believe that the glibc dynamic loader no longer prefers strong definitions to weak ones.
>>> Neither does Darwin’s dynamic loader, this implemenation works there because the static linker _will_ override the weak def with a strong one.  IIUC, binutils ld does this too.
>>> If we need this to work between DSOs then that potentially presents a problem (for Darwin the DSO is identified so that the symbol will be found in the library that resolved it in the static link, [but that can be defeated by forcing “flat linking”]), I am not sure if glibc dynamic loader would do something similar (although this code path is not taken on ELF targets since they have the symbol aliases).
>>>> Perhaps on targets that don't allow weakrefs to be unbound,
>>> Darwin would allow it if we were able to tell the static linker that the symbol is permitted to be undefined - but since we don’t know the symbol’s name outside the FE, that is not going to fly.
>>
>> Can you elaborate on this?
> 
> At runtime Mach-O is much the same as ELF w.r.t weak references, the difference comes at static link time when (by default) Darwin’s linker requires all symbols to have a definition.
> 
> Darwin’s static linker has three mechanisms for allowing a weak reference (in each case, at runtime, the symbol reference will be NULL if no definition is present - so ELF-like at that point):
> 
>   1. A definition is supplied on the link line (usually in a DSO) the DSO is defined as a weak library, which means it is permitted to be absent at runtime.  [the usage we are thinking of here is not what this facility was designed for, but it can work].
> 
> 2. We put -Wl,-undefined,dynamic_lookup on the link line, that allows any symbol to be undefined - it is a massive sledgehammer and not at all recommended for general code (we have to use it for things like plugins that need to resolve many symbols at runtime from their host).  NOTE that it also seems to be incompatible with some modern fixups on arm64 (i.e. it looks like Apple do not intend to guarantee it will work in the future).
> 
> 3. An individual symbol maybe be specified as “allowed to be undefined” by passing -Wl,-U,_symbol
> 
> It was the third case I was thinking of - but I cannot see how to obtain the symbols easily (If we can identify them, we could arrange to emit them into some special section and then fish them out using simple-object in collect2 and apply to the generated link line).  However, this does not seem like a phase3/4 kind of change (and I do not currently have much^W any spare time either).

Aha, thanks.  We shouldn't need to build a list in a special section: 
collect2 could look for _ZTH* symbol references and add -U options for them.

Jason