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

cmd/link: bad reflect data when using -linkshared #18252

Closed
mwhudson opened this issue Dec 8, 2016 · 3 comments
Closed

cmd/link: bad reflect data when using -linkshared #18252

mwhudson opened this issue Dec 8, 2016 · 3 comments

Comments

@mwhudson
Copy link
Contributor

mwhudson commented Dec 8, 2016

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.

mwhudson@aeglos:/opt/opensource/go-test-cases$ cat checkstuff.go
package main

import (
	"fmt"
	"reflect"
)

type C struct {
}

func F(c *C) *C {
	return nil
}

func main() {
	var c *C
	fmt.Println(reflect.TypeOf(F).Out(0) == reflect.TypeOf(c))
}
mwhudson@aeglos:/opt/opensource/go-test-cases$ go run -linkshared checkstuff.go 

What did you expect to see?

true

What did you see instead?

false

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

Yes.

System details

go version devel +d4b46aa Thu Dec 8 01:36:44 2016 +0000 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/opt/opensource/gopath"
GORACE=""
GOROOT="/opt/opensource/go"
GOTOOLDIR="/opt/opensource/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build287398977=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
GOROOT/bin/go version: go version devel +d4b46aa Thu Dec 8 01:36:44 2016 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +d4b46aa Thu Dec 8 01:36:44 2016 +0000 X:framepointer
uname -sr: Linux 4.4.0-47-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.23-0ubuntu4) stable release version 2.23, by Roland McGrath et al.
gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
@crawshaw
Copy link
Member

crawshaw commented Dec 8, 2016

A potential hint:

x := reflect.TypeOf(F).Out(0)
y := reflect.TypeOf(c)
println("x=", x)
println("y=", y)

prints

x= (0x7f7d21ac16c0,0x6028c0)
y= (0x603020,0x6028c0)

So the *rtype being returned for *C is correct, but the interface type for *rtype is incorrect. (That is, it is being sourced from the non-canonical module.) I'd look at the asm for reflect.toType, figure out how it finds *rtype, and make sure it passes through the typeOff map.

@mwhudson
Copy link
Contributor Author

mwhudson commented Dec 9, 2016

toType looks like this:

0000000000a95930 <reflect.toType>:
  a95930:       48 8b 44 24 08          mov    0x8(%rsp),%rax
  a95935:       48 85 c0                test   %rax,%rax
  a95938:       74 12                   je     a9594c <reflect.toType+0x1c>
  a9593a:       48 8d 0d 7f dd fd 00    lea    0xfddd7f(%rip),%rcx        # 1a736c0 <go.itab.*reflect.rtype,reflect.Type>
  a95941:       48 89 4c 24 10          mov    %rcx,0x10(%rsp)
  a95946:       48 89 44 24 18          mov    %rax,0x18(%rsp)
  a9594b:       c3                      retq   
  a9594c:       48 c7 44 24 10 00 00    movq   $0x0,0x10(%rsp)
  a95953:       00 00 
  a95955:       48 c7 44 24 18 00 00    movq   $0x0,0x18(%rsp)
  a9595c:       00 00 
  a9595e:       c3                      retq   
  a9595f:       cc                      int3   

Both the executable and the shared library have a local symbol called "go.itab.*reflect.rtype,reflect.Type". So I guess this is a consequence of https://golang.org/cl/32131 -- and oops, my tests of 1.7 had that cherry-picked into it. Turns out it doesn't happen in the actual 1.7.4 release. Maybe we need a different fix for the bug that was trying to fix.

@gopherbot
Copy link

CL https://golang.org/cl/34173 mentions this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants