cmd/compile: missing types in debug_info

[aarzilli]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version devel +2b445c7 Sat Nov 5 23:59:04 2016 +0000 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/a/n/go/"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build237842021=/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"

What did you do?

Compiled this with go build -gcflags='-N -l'

What did you expect to see?

I expected .debug_info to have entries for the anonymous types map[string]main.astruct, []main.astruct and for the named type main.astruct.

What did you see instead?

None of those.

I presume this is deliberate and types that are not referenced by any variable are pruned from debug_info. In delve to print the value of an interface variable we used to parse the value of their tab._type field to reconstruct the name of the type and then look that up in debug_info, how should we do this now? If the answer is "you should use runtime._type directly" then at least runtime.slicetype, runtime.arraytype, runtime.maptype, etc... should always be included in debug_info so that we don't have to hardcode them into the debugger for every version of go.

[dr2chase]

@crawshaw is this related to your recent changes?

[crawshaw]

The only change I've made recently to type information is exporting more symbols when building plugins, which shouldn't have anything to do with this. Maybe you mean someone else's changes?

[aarzilli]

Looks like this is a side-effect of 9c066ba

[gopherbot]

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

[mdempsky]

If I understand correctly, the issue isn't actually that you need DWARF type info for temporary variables, but you need the DWARF type info for map-related struct types, and we used to only emit those because they were referenced in temporary variables?

I.e., reverting to the previous behavior where we emit DWARF type info for temporary variables fixes the issue, but really we just need to ensure that we emit info for all of those map-related struct types regardless of whether they're used as temporaries?

[aarzilli]

It isn't just map types, if you look at the example type info for main.astruct isn't emitted either.

[mdempsky]

@aarzilli Ah, thanks. I misread the type name in the bug report and thought you were talking about map.bucket or something.

[mdempsky]

In delve to print the value of an interface variable we used to parse the value of their tab._type field to reconstruct the name of the type and then look that up in debug_info, how should we do this now?

@aarzilli I was re-reviewing the fix for this issue, and I'm wondering: what does delve do with types that are constructed at runtime using reflect APIs? E.g., how does it handle:

package main

import (
	"fmt"
	"reflect"
)

type astruct struct {
	a, b int
}

func main() {
	stringTyp := reflect.TypeOf("")
	astructTyp := reflect.TypeOf((*astruct)(nil)).Elem()

	var iface interface{} = reflect.MakeMap(reflect.MapOf(stringTyp, astructTyp)).Interface()
	var iface2 interface{} = reflect.MakeSlice(reflect.SliceOf(astructTyp), 0, 0).Interface()
	fmt.Println(iface, iface2)
}

[aarzilli]

@mdempsky they are not supported. I have considered writing code to read the runtime._type and turn it directly into a dwarf.Type (without going through debug_info) but:

a) I would need the specialized versions of runtime._type (i.e. runtime.slicetype, runtime.maptype, etc) to be exported to debug_info.
b) it's a lot of work for something that has minimal use, so I've been putting it near the bottom of the list of things I should do for delve

For (a) I was hoping to propose this change during 1.9 since they are useful for other stuff, (b) is somewhat more fundamental.