DNM: stdlib: Add backward deployment versions for the dynamic-replacement runtime functions - version 2

[eeckstein]

This will allow backward deployment to a swift 5.0 runtime.
It also needs a different mechanism to pass the "implicit" boolean parameter in the thread local storage: Instead storing it in a boolean field, we use bit 0 of the AccessSet Head.
This avoids changing the layout of the thread local storage and makes it compatible with the swift 5.0 runtime.

rdar://problem/51601233

This PR is another possibility to implement this feature. The first version is #25340

[eeckstein]

@swift-ci smoke test

[mikeash]

I'm really wary about baking this into apps. These are pretty simple functions, which means there isn't much potential for breaking changes, but I'm paranoid that something would come up eventually.

Can we find a way to make these call the versions from libswiftCore.dylib if they exist? ARCLite accomplishes this using a terrifying technique that involves patching entries in the lazy pointer section at runtime. We could potentially do that, although it is scary.

Another option might be to use dlsym in these functions to try to find one in libswiftCore, and then call through to it if it exists. That would add a bit more overhead but it wouldn't be too horrible.

We could cut down on that overhead by having the static library include global variable function pointers that point to these functions, similar to how swift_retain etc. work. When code is compiled for older targets, have it call through the function pointers. The function pointers can point to something that decides whether to use the version from libswiftCore or the version here, then writes the appropriate function pointer back to the global variable.

[aschwaighofer]

Yes. Andy pointed out that the current implementation would bake in the ABI of how we do things.

Jordan and I talked yesterday and he proposed marking the functions in the libswiftCore.dylib weak. Something like

libswiftCore.dylib:

__attribute__(weak) // or is that __attribute__(weak_import)
void *swift_getReplacement();

The compatibility archive can then check whether the weak symbols is bound and use it if it is otherwise fall back to a compatibility version. This way you always get the current implementation and only fall back if there is not implementation. The fallback does not become ABI this way.

libcompatdynrepl.a:

void *swift_getReplacement50() {
  if (swift_getReplacement)
    return swift_getReplacement()
  ... fallback implementation
}

[mikeash]

Good call, this is like my dlsym idea except much better.

[aschwaighofer]

Follow-up as discussed: #25473