I don't understand initial exec TLS model. But I meet the following problem
when use go shared library. *When I load Go shared library from python2.7
script on alpine 3.9 container.**Would you please give some suggestions? I
am so appreciated for your help!*
*When I call Go shared library from python2.7 script on alpine 3.9
container.*failed with OSError: Error relocating ./cc.so: : initial-exec
TLS resolves to dynamic definition in ./cc.so
<https://stackoverflow.com/questions/55642942/python-on-alpine-ctypes-loadlibrary-failed-with-oserror-error-relocating-cc>
/usr/src/app # go build -o cc.so -buildmode=c-shared main.go
/usr/src/app # readelf -d cc.so
Dynamic section at offset 0x10cd10 contains 22 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.musl-x86_64.so.1]
0x0000000000000010 (SYMBOLIC) 0x0
0x000000000000000c (INIT) 0x42000
0x000000000000000d (FINI) 0x92ed9
0x0000000000000019 (INIT_ARRAY) 0xa2078
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x270
0x0000000000000005 (STRTAB) 0xa50
0x0000000000000006 (SYMTAB) 0x378
0x000000000000000a (STRSZ) 1026 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x10deb0
0x0000000000000002 (PLTRELSZ) 720 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x41a00
0x0000000000000007 (RELA) 0xe58
0x0000000000000008 (RELASZ) 265128 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000000000001e (FLAGS) SYMBOLIC BIND_NOW STATIC_TLS
0x000000006ffffffb (FLAGS_1) Flags: NOW NODELETE
0x000000006ffffff9 (RELACOUNT) 11040
0x0000000000000000 (NULL) 0x0
/usr/src/app # python test.py
Traceback (most recent call last):
File "test.py", line 2, in
lib = ctypes.cdll.LoadLibrary('./cc.so')
File "/usr/lib/python2.7/ctypes/init.py", line 444, in LoadLibrary
return self._dlltype(name)
File "/usr/lib/python2.7/ctypes/init.py", line 366, in init
self._handle = _dlopen(self._name, mode)
OSError: Error relocating ./cc.so: : initial-exec TLS resolves to dynamic
definition in ./cc.so
- show quoted text -
Code:
//main.go package main import "C" //export add func add(left, right int)
int { return left + right } //export minus func minus(left, right int) int
{ return left - right } //export multiply func multiply(left, right int)
int { return left * right } //export divide func divide(left, right int)
int { return left / right } //export testPrint func testPrint(){
print("test") } func main() { } // test.py import ctypes lib =
ctypes.cdll.LoadLibrary('./cc.so') if lib is not None: print ("can load so")
On Thursday, May 30, 2013 at 4:16:35 AM UTC+8, Elias Naur wrote:
>
> Hi,
>
> A few months ago, I got some CLs reviewed and submied that added some low
> level work towards support for creating shared libraries written in Go. The
> more intrusive runtime changes were never accepted, so I'd like to propose
> a more clean, simple, and hopefully more acceptable way of supporting
> shared library in the Go runtime and tools. This proposal uses linux
> terminology, but shared libraries on the other OSes are (hopefully) similar.
>
> *Go shared libraries*
> Supplying the -shared flag to 6l will output a shared library that is
> similar to a go program, but with a few notable differences:
>
> Just as a go program includes all the referenced go code and the go
> runtime, a go shared library is a dynamic shared object (.so file) that
> includes all the referenced go code and the runtime.
>
> When a go program is executed, the main thread calls into the Go runtime,
> which is initialized, init functions are run and finally, main() is run. A
> go library does not own the native program's main thread, and in fact might
> not even be loaded from the main thread (in the dlopen() case).
> Instead, the thread loading the go library spawns a new thread which from
> then on functions as the Go main thread. The fresh go main thread in turn
> runs go runtime initialization and then notifies the loading thread to
> return control to the main program. The runtime initialization for go
> libraries is the same as for ordinary go programs, except that main() is
> expected to return, and that go won't exit the program when that happens.
> I don't have strong feelings about running main() or not, but running it
> is the closest to normal go program behaviour, and then main() can double
> as a "library init" function.
> After initialization, the main program can call into the Go library just
> as if a foreign thread called into Go in a Cgo program.
>
> Deadlock detection is effectively disabled in go libraries, even if no cgo
> calls have been made from Go, because it can't be known whether the main
> program is deadlocked or not.
>
> os.Args normally contain the programs arguments. Shared libraries
> generally don't have access to the program arguments without cooperation
> from the main program, so os.Args length is 0 for go libraries.
>
> *Linux/amd64 implementation*
> To test the proposal and to make sure it is complete, I've added support
> for go shared libraries to the linux/amd64 platform. It builds on the
> existing -shared flag, and on the recent support for external linking and
> callbacks from foreign threads.
>
> The low level and less intrusive changes are in
> https://codereview.appspot.com/9733044/. It reimplements -shared in 6l
> with external linking and adds support for the initial exec TLS model. This
> CL contains what I believe is the necessary linker changes for go shared
> library support, regardless of how the runtime changes and user visible
> semantics end up to be. If my runtime proposal is not accepted, it is my
> hope that this CL can be reviewed on any technical problems and submitted
> anyway.
>
> The runtime changes are in https://codereview.appspot.com/9738047/. It
> contain the meat of the proposal and I expect this CL to contain the most
> controversy, if any. The CL also includes a test for a basic C program
> linking to a go library and a more advanced C program that dlopen()s a go
> library and use __thread TLS variables.
>
> The implementation has some limits that are not inherent in the proposal:
>
>
> - Shared library support is not "out of the box", in the sense that Go
> (on amd64) must be built with the -largemodel flag to gc and cc to support
> go libraries. Ordinary go programs can still be built with those flags,
> but
> the position independent code and the initial exec TLS model makes the
> resulting executables slightly slower. This restriction is similar to the
> race detector, which also needs a special build to function. Ideally, the
> same Go build should support both ordinary go programs and go libraries
> without any unnecessary speed penalty. Advice on how to implement that in
> the tooling is welcomed.
> - Multiple go libraries loaded in the same native program, or a go
> program loading a go library probably won't work. An immediate showstopper
> is that cgo currently exports some symbols (x_cgo_init etc.) in all go
> libraries
> and programs. Multiple go libraries are also inefficient, in the sense
> that
> they won't share a single runtime, heap, garbage collector, etc.
> - No go tool flag ("-shared"?) has been added yet, but can be
> trivially added.
>
>
> *Linux/arm *
> The basic -shared flag support is already present on linux/arm, and I plan
> to implement this updated proposal for linux/arm too. However, since
> external linking is now required, I'd like to know if anyone (Russ?) is
> already working on that? If not, I'd like to go ahead and attempt an
> implementation of external linking myself.
>
> - elias
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
