fix GH-24262: default apache build to global-dynamic TLS

[henderkes]

... use --with-tsrm-tls-model=initial-exec to explicitly override it

closes #24262
split off from #23227

@ndossche @arnaud-lb

Are there any plans to make pcre or ext-URI buildable as shared modules? If not, we should probably add TSRM_TLS_MODEL attribute to their __thread variables too. They currently get no model and the slow access sequence, but still count towards the static tls surplus budget - it's really weird.

[arnaud-lb]

Apparently there is only one PT_TLS segment per ELF object, so all TLS variables ends up in the same segment regardless of the model. If one of them needs static TLS the binary gets a DF_STATIC_TLS and the entire segment must be reserved into static TLS. In theory the linker could relax all GD to IE in that case, I'm not sure why it doesn't.

I agree that we could add the TSRM_TLS_MODEL attribute as it wouldn't increase the static TLS budget. I suggest to do it only on master.

[henderkes]

Yes, good idea. Since zend already includes tsrm, we could just change the ZEND_TLS definition on master.

[ndossche]

All the threading complications are not nice of course, but it is what it is.
Thanks for tackling this.

[henderkes]

Hold on before merging this, I just stumbled across -ftls-model=... https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html.

I think instead of forcing global-dynamic or adding our own option, we can instead default to no tls model and advise to add -ftls-model=initial-exec.

It results in the same effect, no tls model specified means global-dynamic for shared libraries, but we wouldn't need a --with-tsrm-tls-model= option. Although maybe it's better if it shows up in configure help.

[henderkes]

Back to draft because I don't want to push to an approved PR.

What do you think? Go with the explicit configure option, or advise to overwrite the default with -ftls-model?

[henderkes]

This is still an extra block under PIC && !PIE instead of adding it above, because we want to keep the explicit local-exec choice in !PIC || PIE.

[arnaud-lb]

The new version is better 👍

[ndossche]

I have concerns:

• Now a slower TLS model will likely be used. This raises the question whether it was worth moving AG & SCNG into the TLS section, which seems to have caused this in the first place.
• With -ftls-model=initial-exec in CFLAGS, TSRM_TLS_MODEL_USE_DEFAULT is still defined. This mean, tsrm_get_ls_cache_tcb_offset() going to return 0 and not use the fast path. This is not desirable.

[henderkes]

Now a slower TLS model will likely be used. This raises the question whether it was worth moving AG & SCNG into the TLS section, which seems to have caused this in the first place.

Another 256 bytes came from ext-uri (added in 8.6). They don't need fast tls access, but like Arnaud explained still count towards the budget. So we'll either need to refactor that, and a bunch of other tls variables, or go the only route that is safe for dlopen()ed libraries - which is this.

With -ftls-model=initial-exec in CFLAGS, TSRM_TLS_MODEL_USE_DEFAULT is still defined. This mean, tsrm_get_ls_cache_tcb_offset() going to return 0 and not use the fast path. This is not desirable.

Ah yeah, Apache would get the slow jit. Let me fix that.

[henderkes]

Opened the other approach in a draft PR, but like I said there, definitely favour this approach. For one it leaves the path open to using more thread storage directly in the future, which will directly benefit performance, without worrying about static TLS. It also benefits musl and other OSes that don't have a static TLS surplus. Perhaps we can even do away with the whole macro block in tsrm.h and just set the right model directly via build system (linked against = initial-exec, not linked against = global-dynamic).

[ndossche]

Now okay I think