golang/go

cmd/compile: functions are inlined beyond boundary of shared libraries

hirochachacha opened this issue · 3 comments

Please answer these questions before submitting your issue. Thanks!

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

$ go install -buildmode=shared std
$ go get -buildmode=shared -linkshared github.com/hirochachacha/foo
$ ls $GOPATH/pkg/linux_amd64_dynlink/libgithub.com-hirochachacha-foo.so
/go/pkg/linux_amd64_dynlink/libgithub.com-hirochachacha-foo.so
$ cat foo.go
package main

import (
	"github.com/hirochachacha/foo"
)

func main() {
	foo.Bar()
}

$ go build -linkshared foo.go
$ ./foo
Bar
$ ldd foo
    linux-vdso.so.1 (0x00007fff0c3aa000)
    libstd.so => /root/go/pkg/linux_amd64_dynlink/libstd.so (0x00007f6b4c582000)
    libgithub.com-hirochachacha-foo.so => /go/pkg/linux_amd64_dynlink/libgithub.com-hirochachacha-foo.so (0x00007f6b4c37e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b4bfcc000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6b4bdc8000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6b4bbab000)
    /lib64/ld-linux-x86-64.so.2 (0x0000561ba7f94000)
$ nm -u foo
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
                 w _Jv_RegisterClasses
                 w __gmon_start__
                 U __libc_start_main@@GLIBC_2.2.5
                 U go.link.abihash.libgithub.com-hirochachacha-foo.so
                 U go.link.abihash.libstd.so
                 U main
                 U runtime.addmoduledata
                 U runtime.morestack_noctxt
                 U runtime.printlock
                 U runtime.printnl
                 U runtime.printstring
                 U runtime.printunlock
                 U runtime.throwinit
                 U runtime.tlsg
                 U type.uint8

So, the executable is linked to my own shared library, but the function is inlined.

What did you expect to see?

No inlined. foo.Bar() is called via the shared library.

What did you see instead?

Inlined.

Does this issue reproduce with the latest release (go1.8.3)?

Yes.

System details

go version devel +583a941 Tue Aug 15 10:10:42 2017 +0000 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/root/go"
GOTOOLDIR="/root/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build802469124=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version devel +583a941 Tue Aug 15 10:10:42 2017 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +583a941 Tue Aug 15 10:10:42 2017 +0000
uname -sr: Linux 4.9.31-moby
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.19-18+deb8u10) stable release version 2.19, by Roland McGrath et al.
gdb --version: GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1

I'm not sure whether this is working as intended or not.

I don't know about intended, but it's expected and I admit a little surprising. The fix would be to strip out the inlinable bodies from the export data when linking a shared library but I don't think I'm going to get around to this any time soon...

Obsoleted by #47788