[cpullvm] Force a consistent TLS model for all library builds using picolibc#377
Merged
Jonathon Penix (jonathonpenix) merged 3 commits intoMay 21, 2026
Conversation
Previously, a TLS model was only ever explicitly set for picolibc--other projects (libc++, etc.) would use whatever the compiler selected. This shouldn't necessarily be a problem, but in practice can cause issues when global-dynamic is selected and is implemented via calls to `__tls_get_addr` (ex: in our 32bit Arm and 32/64bit RISC-V PIC configs). Given we don't provide an implementation and we don't expect people to use a dynamic linker that would implement this, people will generally get undefined reference errors. See the discussion in qualcomm#341. To try and address this, consistently specify a TLS model across all of the libraries we are building. Note that this seems to primarily be an issue with picolibc as it uses "normal" TLS mechanisms [1]. musl-embedded doesn't seem to (see ex: `__errno_location`) and consequently I don't see any obvious TLS usage in any of our libraries built with musl-embedded as the libc. However, I don't know if this holds true in general (if ex: libc++ itself will never have "normal" TLS accesses of it's own). And, given that the usecases we expect for our picolibc variants are the same as for our musl-embedded variants (and these expectations in turn match the restrictions imposed by the given TLS model), I'm erring on the side of specifying the TLS model for variants which use musl-embedded as well. [1] https://github.com/picolibc/picolibc/blob/main/doc/tls.md Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
Ana Pazos (apazos)
approved these changes
May 21, 2026
Jonathon Penix (jonathonpenix)
merged commit f46b424
into
qualcomm:release/qualcomm-software/22.x
8 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, a TLS model was only ever explicitly set for picolibc--other projects (libc++, etc.) would use whatever the compiler selected. This shouldn't necessarily be a problem, but in practice can cause issues when global-dynamic is selected and is implemented via calls to __tls_get_addr (ex: in our 32bit Arm and 32/64bit RISC-V PIC configs). Given we don't provide an implementation and we don't expect people to use a dynamic linker that would implement this, people will generally get undefined reference errors. See the discussion in #341.
Note that this seems to primarily be an issue with picolibc as it uses "normal" TLS mechanisms [1]. musl-embedded doesn't seem to (see ex: __errno_location) and consequently I don't see any obvious TLS usage in any of our libraries built with musl-embedded as the libc.
To try and address this, consistently specify a TLS model across all of the libraries we are building when using picolibc.
For musl-embedded, given that a) it is generally not expected to be thread safe b) it doesn't seem to use the "usual" TLS mechanisms from the toolchain as mentioned above and c) historically we haven't had any special handling downstream for this, musl-embedded configs are intentionally excluded here.
Since we're special casing the flag on the libc type now, at the same time add basic error checking so we aren't silently dropping this if it is specified via JSON.
[1] https://github.com/picolibc/picolibc/blob/main/doc/tls.md