If a TLV stub is called from a dylib, dyld_stub_binder will clobber r11.
Fixes PR51703.
Differential D109112
[darwin/x86] Model cxx_fast_tlscc as not preserving r11 thakis on Sep 1 2021, 4:50 PM. Authored by
Details
If a TLV stub is called from a dylib, dyld_stub_binder will clobber r11. Fixes PR51703.
Diff Detail Event TimelineComment Actions Hmm, I wonder if there's a compatibility problem for changing this; I hadn't realized this was so old. It dates to 2015 (r252837), in a commit by Manman. Comment Actions What's the next step here? Do you want to run some internal tests? Do you want me to run some tests? Use a different approach? Comment Actions Should we just land this and see what (if any) breaks? We do know that it fixes a miscompile of fairly basic code. Comment Actions Hmm, I think the potential problem here is that dropping R11 from CSR_64_TLS_Darwin does not only change the calling code (which is what we want, and seems like a safe change), but will also change the callee, i.e. the TLS wrapper functions wherever they're generated, to no longer preserve R11 (which they did before, although not when called through the dyld_stub_binder). That would cause a problem if the caller and callee are built by different compiler versions (e.g. an older program calling some newer (system?) library code). I don't know whether that could happen though? (These registers are also tied up with "split CSRs" somehow, which was added by https://github.com/llvm/llvm-project/commit/abc7c1d1d2d44b4d7416c714a13239872d95a72e followed by AArch64-specific code in https://github.com/llvm/llvm-project/commit/cbe4f9417d1cbb0192173439501fedb782949bad and then x86_64 in https://github.com/llvm/llvm-project/commit/ed967f37520fec398aa419514de552e1a917c9ec Comment Actions rjmccall, do you have any opinion on what (if anything) should happen here? At the moment, using TLV across dylibs on darwin is basically broken (see https://github.com/llvm/llvm-project/issues/51045). This is a fairly simple fix. It carries some risk, but maybe not having it is worse? Comment Actions I think I can speak authoritatively at this point that the right way to understand this convention is:
I'll leave it to LLVM folks to decide how they want to model that. |