Skip to content
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

Open
charleskorn opened this issue Sep 1, 2022 · 9 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@charleskorn
Copy link

Splitting out from #13492:

@ansiwen's comment:

For what it's worth, compiled with -buildmode=c-shared I get:

sc_dlopen failed: Error relocating ./foobar.so: (null): initial-exec TLS resolves to dynamic definition in ./foobar.so

with

$ go version
go version go1.17.5 linux/amd64
$ cat /etc/alpine-release 
3.15.0
$ apk version musl
Installed:                                Available:
musl-1.2.2-r7                           = 1.2.2-r7 

I am still seeing a similar issue today with Go 1.19.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Sep 1, 2022
@heschi
Copy link
Contributor

heschi commented Sep 1, 2022

cc @golang/runtime

@heschi heschi added the NeedsFix The path to resolution is known, but the work has not been done. label Sep 1, 2022
@heschi heschi added this to the Backlog milestone Sep 1, 2022
@mknyszek
Copy link
Contributor

mknyszek commented Sep 1, 2022

I suspect this is more compiler related (based on the other thread), so CC @golang/compiler

@charleskorn
Copy link
Author

@mknyszek I see you've added the help wanted label. I've never done any work in the Golang runtime or compiler, but I'm happy to have a go at fixing this if someone can give me some pointers on where to start and a reasonable approach to take - is this something you can help me with?

@richfelker
Copy link

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 LD_PRELOAD, not if they will be loaded (directly or indirectly as dependencies) via dlopen. My understanding is that the golang compiler does not yet implement the dynamic TLS access models, so if that's still the case, fixing this bug depends on implementing that.

@jgowdy
Copy link

jgowdy commented Oct 11, 2022

Is there a feature request for implementing the global-dynamic TLS model in Golang? This would be very valuable for my project.

adambenhassen added a commit to adambenhassen/go that referenced this issue Sep 6, 2024
…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
adambenhassen added a commit to adambenhassen/go that referenced this issue Sep 6, 2024
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
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/610837 mentions this issue: runtime: fix segfault due to missing argv on musl-linux c-archive

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/644975 mentions this issue: cmd/asm,cmd/link,cmd/go: Add dynamic TLS model for ARM64

amusman added a commit to amusman/proposal that referenced this issue Jan 28, 2025
For golang/go#54805

Change-Id: Ie6f3641dbea4a4e0993289f8db25bbe6c228724c
GitHub-Last-Rev: fd5b052
GitHub-Pull-Request: golang#56
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/644615 mentions this issue: design: add 54805-go-dynamic-tls.md

amusman added a commit to amusman/proposal that referenced this issue Feb 26, 2025
For golang/go#71953
For golang/go#54805

Change-Id: Ie6f3641dbea4a4e0993289f8db25bbe6c228724c
GitHub-Last-Rev: fd5b052
GitHub-Pull-Request: golang#56
amusman added a commit to amusman/proposal that referenced this issue Feb 27, 2025
For golang/go#71953
For golang/go#54805

Change-Id: Ie6f3641dbea4a4e0993289f8db25bbe6c228724c
GitHub-Last-Rev: fd5b052
GitHub-Pull-Request: golang#56
@tudor-timcu
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
Development

No branches or pull requests

8 participants
@mknyszek @jgowdy @charleskorn @gopherbot @richfelker @tudor-timcu @heschi and others