Re: Would an increase to PTHREAD_KEYS_MAX be an example of a FreeBSD ABI change? (lang/rust involved in why I ask)

On 5/15/26 11:37, Mark Millard wrote:
> On 5/14/26 11:30, Mark Millard wrote:
>> Would an increase to PTHREAD_KEYS_MAX be an example of a FreeBSD ABI change?

It turns out that the lang/rust port disabled the llvm/ELF based TLS
support in a commit earlier on the same day that stable/14 and
releng/14.3 got its R_ARM_TLS_TPOFF32 correction commit fixing its
handling on 2024-11-22. At the time, the posix based operation worked to
build lang/rust . But, as of 1.94.0, the posix implementation of TLS
support was no longer sufficient to build lang/rust , getting "out of
TLS keys" failures instead.

Once 1.95.0 is buildable again (if it proves so via reverting the
lang/rust port patching that avoided compiler based TLS use), a
sysutils/rustic build can be tested on armv7: it is the example OpenBSD
referenced as an example of getting "out of TLS keys" failures in its
commit increasing 256 to 512.

If sysutils/rustic builds, no evidence would be left suggesting an issue
for the armv7 FreeBSD OS.

The details here fit with armv7 being the only FreeBSD platform having
the lang/rust 1.95.0 build issues, one of the things that was
non-obvious but observed.


Much of the above general structure is from Robert C. and I looked up
details and used them.


Old notes for context:

>>
>>
>> Why I ask: an active failure for at least rust use on armv7 . . .
>>
>> The armv7 1.94.0 rust-bootstrap used to try to build 1.95.0 of lang/rust
>> for armv7 gets the Thread Local Storage failure "Out of TLS keys".
>>
>> The same was true for the armv7 1.93.0 rust-bootstrap used to try to
>> build the armv7 1.94.0:
>>
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294545>
>> (Robert Clausecker, not me.)
>>
>>
>> OpenBSD increased PTHREAD_KEYS_MAX to 512 to avoid getting such "Out of
>> TLS keys" failures, not necessarily for armv7 or for building rustc:
>>
>> <https://github.com/openbsd/src/commit/f90c65410264d8346b711e36bca7ee1f0dde5ca9>
>> (2025-11-11)
>>
>> QUOTE from OpenBSD's commit:
>> bump PTHREAD_KEYS_MAX to 512
>> the rust libstd emutls version is using one pthread_key per
>> thread-variable. it means the maximum number of thread-variable at a
>> time is PTHREAD_KEYS_MAX.
>>
>> with recent rustc 1.91.0, we start hiting the limit while compiling some
>> programs (like sysutils/rustic).
>>
>> ok robert@
>> "Let's go 512 and hope someone eventually does proper TLS" deraadt@
>> END QUOTE
>>
>> I think they had 256 previous to the change, not just 128.
>>
>> (The "libstd emutls version" may not be always involved for rust's
>> context? Also: the failure type is apparently not limited to building
>> the rust compiler/toolchain. The overall issue is not FreeBSD OS specific.)
>>
>>
>> Note: It appears that the official FreeBSD port-package building for
>> armv7 stopped shortly before this started to be an issue. That is why
>> fallout reports have not been accumulating for the "out of TLS keys" issue.
>>
>>
>> If increasing PTHREAD_KEYS_MAX is an ABI change, an implication is that
>> 14.*-RELEASE and 15.*-RELEASE could not be changed, possibly eliminating
>> rust use on armv7 going forward.
>>
>>
>> Note:
>> It is my understanding that alternate Thread Local Storage models for
>> rust require use of rust-nightly (unstable) builds instead of stable
>> rust builds.
>>
>>
> 
> [Replied to original to associate with the overall problem, without lots
> of other detail.]
> 
> There seems to be confusion on if rust 1.95.0 is fixed vs. improved for
> the "out of TLS keys" issue. I'll quote another OS's results on that:
> 
> <https://github.com/rust-lang/rust/issues/155758#issuecomment-4351327231>
> 
> QUOTE
> . . . Rust 1.95.0 does improve the situation on Haiku, but it does not
> fully fix it. With 1.95.0, some packages that failed for me on 1.94.1
> now build successfully. However, I still have packages that fail with
> the same fatal error on 1.95.0, while those same packages build
> successfully with 1.89.0.
> END QUOTE
> 
> (Haiku jumped from 1.89.0 to 1.94.1 to 1.95.0, skipping all the
> 1.9[0123].0 .)
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com