Good grief.
I will check this over the weekend. Honestly I hope there's another way. This is quite complex.

Thank you @nielsdos. It's not incredibly complex when considering that we compare the bytecode verbatim (ignoring the imm operands). There is no full blown bytecode decoding or interpreting.

In intel bytecode imms are encoded on whole bytes, so we compare the rest. In arm we mask the imms out of the fixed-size 32bit instructions before comparison.

In zend_jit_resolve_tsrm_ls_cache_offsets() there are just two possibilities:

1. The bytecode is exactly what we emitted.
2. The bytecode changed, and is exactly what we expect the linker may have emitted instead.

In both cases we extract imm values at fixed positions in the bytecode. The rest is what we did before: In the first case the imm values give us the address of the TLS descriptor, and in the second case the TCB offset.

Yes I understood the idea on a high level, but considering it deals with different platforms and instruction encodings, I would not call it simple. I wish there was a different solution

I wish too. Unfortunately I didn't find a good alternative.

Here is what I've checked:

• Disabling linker relaxation would have solved the issue, but it's not possible. Relaxation is just part of relocation processing and can not be disabled, in linkers I've checked.
• Forcing _tsrm_ls_cache to use the global-dynamic model or using a JIT-specific TSRM cache variable with a forced model might work, but using this model in JIT is slower. One additional benefit of this PR is that it makes the symfony demo benchmark 3% faster in some cases, because JIT is now able to use the local-exec model in these cases. Also I can't seem to be able to actually force the dynamic model.
• Emitting code that's not eligible for relaxation (already relaxed), so the linker doesn't attempt it, would have worked as well. E.g. emitting _tsrm_ls_cache@gottpoff when we know the variable is eligible for the local-exec model, or _tsrm_ls_cache@tlsgd otherwise. But we can not know that in advance, e.g. a static archive of PHP may be ultimately linked into a shared library or an executable, making gottpoff invalid in the former case or tlsgd relaxable in the latter.
• Having a separate TSRM cache for JIT, backed by pthread_get_key / pthread_getspecific so we don't have to deal with relocations. This is what v8/jsc do as far as I can see, but they only support "inlining" pthread_getspecific on MacOS and Windows. Unfortunately inlining it on all platforms we care about would rely on considerably more platform/libc specificity, with no ABI guarantees at all.