-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime: c-shared builds fail to load with dlopen with musllibc: initial-exec TLS resolves to dynamic definition
#54805
Comments
cc @golang/runtime |
I suspect this is more compiler related (based on the other thread), so CC @golang/compiler |
@mknyszek I see you've added the |
This is happening because go is producing shared libraries with initial-exec accesses to TLS objects defined in them. As the name implies, the initial-exec access model is only valid for accessing TLS objects present at initial exec time, not ones dynamically loaded later. So shared libraries can use it only if they are loaded at program load time as a dependency or via |
Is there a feature request for implementing the global-dynamic TLS model in Golang? This would be very valuable for my project. |
…rchive This change fixes a segmentation fault that occurs on musl-based systems when using c-archive (or c-shared with LD_PRELOAD). The issue was caused by uninitialized argv and envp, which led to crashes at runtime. This fix ensures that both argv and envp are correctly initialized, preventing the segmentation fault. While this fix addresses crashes due to missing argv and envp, it does not address the error described in issue golang#54805, where a c-shared library loaded with dlopen triggers an error related initial-exec access to TLS objects [1] in a dynamically loaded library. [1]: http://git.musl-libc.org/cgit/musl/commit/?id=5c2f46a214fceeee3c3e41700c51415e0a4f1acd Fixes golang#13492
This change fixes a segmentation fault that occurs on musl-based systems when using c-archive (or c-shared with LD_PRELOAD). The issue was caused by uninitialized argv and envp, which led to crashes at runtime. This fix ensures that both argv and envp are correctly initialized, preventing the segmentation fault. While this fix addresses crashes due to missing argv and envp, it does not address the error described in issue golang#54805, where a c-shared library loaded with dlopen triggers an error related initial-exec access to TLS objects [1] in a dynamically loaded library. [1]: http://git.musl-libc.org/cgit/musl/commit/?id=5c2f46a214fceeee3c3e41700c51415e0a4f1acd Fixes golang#13492
Change https://go.dev/cl/610837 mentions this issue: |
Change https://go.dev/cl/644975 mentions this issue: |
For golang/go#54805 Change-Id: Ie6f3641dbea4a4e0993289f8db25bbe6c228724c GitHub-Last-Rev: fd5b052 GitHub-Pull-Request: golang#56
Change https://go.dev/cl/644615 mentions this issue: |
For golang/go#71953 For golang/go#54805 Change-Id: Ie6f3641dbea4a4e0993289f8db25bbe6c228724c GitHub-Last-Rev: fd5b052 GitHub-Pull-Request: golang#56
For golang/go#71953 For golang/go#54805 Change-Id: Ie6f3641dbea4a4e0993289f8db25bbe6c228724c GitHub-Last-Rev: fd5b052 GitHub-Pull-Request: golang#56
Hello! I saw a recent design doc and a branch for an arm64 fix for this. Is there any estimate date in sight for fixing this for x86_64? Thank you! |
Splitting out from #13492:
@ansiwen's comment:
I am still seeing a similar issue today with Go 1.19.
The text was updated successfully, but these errors were encountered: