On 1/4/23 10:30, Iain Sandoe wrote:
On 4 Jan 2023, at 15:03, Jason Merrill <ja...@redhat.com> wrote:
On 1/3/23 18:17, Iain Sandoe wrote:
On 3 Jan 2023, at 22:22, Jason Merrill <ja...@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
