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 · 5 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.

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

7 participants
@mknyszek @jgowdy @charleskorn @gopherbot @richfelker @heschi and others