cmd/compile: Compiler doesn't expand paths specified in the //line directive

[nd]

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

$ go version
go version go1.15beta1 linux/amd64

Does this issue reproduce with the latest release?

yes

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/nd/.cache/go-build"
GOENV="/home/nd/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/nd/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/nd/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/nd/go/go1.15beta1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/nd/go/go1.15beta1/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build338441636=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Compiled code containing //line directives. Code has the following structure:

• $GOPATH/gen/f.go:

package main

import "gen/pkg"

func main() {
	F("ok")     
	pkg.F("ok")
}

func F(s string) {
//line foo:2
	println(s)
}

• $GOPATH/gen/foo:

function F(var s) {
  println(s)
}

• $GOPATH/gen/pkg/f.go:

package pkg

func F(s string) {
//line foo:2
	println(s)
}

• $GOPATH/gen/pkg/foo:

function G(var s) {
  println(s)
}

Code is compiled with go build -gcflags="all=-N -l" .

What did you expect to see?

Debug info contains 2 entries: path/to/gen/foo and path/to/gen/pkg/foo.

What did you see instead?

A single file entry:

 The Directory Table is empty.

 The File Name Table (offset 0x1cadb):
  Entry Dir     Time    Size    Name
  1     0       0       0       <autogenerated>
  2     0       0       0       /home/nd/go/src/gen/f.go
  3     0       0       0       foo
  4     0       0       0       /home/nd/go/src/gen/pkg/f.go

[davecheney]

I believe this working as intended; //line replaces the natural line inferred during compilation with the contents supplied. If you say foo, you get foo.

[aarzilli]

Is this about some tool in particular? I think you are getting exactly what you are asking for here, maybe context would help.

[nd]

Ok, so generator is responsible for generating full paths inside the //line comments? I thought the compiler could make full path if the filename inside the comment is not already absolute.

Is this about some tool in particular?

go2go and goyacc don't generate full paths, that's why I thought they expect compiler to expand those.

[aarzilli]

Ok, so generator is responsible for generating full paths inside the //line comments?

If that was the case then you couldn't commit the output of the generator. I don't know.

[davecheney]

The issue of full or abbreviated path names has no resolution. Some want the complete path, their counterparts view that as information leakage and ask for options to remove it.

The behaviour of //line simply replaces whatever the compiler was going to embed into the dwarf information with the value specified. Note that this information may later be stripped out of the binary.

I would like to close this issue as I don't see a bug or a proposal to change the current behaviour (noting the inherent conflict stated above)

[nd]

Not insisting on a fix, but current behavior makes it harder to find source of a generated code in debugger. I thought that //line directives are intended to help with that. Given that information can be stripped and full go file names are already in executable, expanding //line filenames doesn't introduce serious leakage?

If the issue wasn't raised before, then maybe it's not that important.

[davecheney]

I think the solution isn't to change the compiler, but change the code generator that is making those //lines.

[cagedmantis]

/cc @randall77 @griesemer

[randall77]

I agree with @davecheney - whatever is inserting the line directives should be expanding them, if that's what they want.

The same thing happens in C. If you have a C file:

#include <stdio.h>

int main(int argc, char *argv[]) {
  printf("%s\n", __FILE__);
#line 7 "foo.c"
  printf("%s\n", __FILE__);
}

If you put that C file in some directory, you will get the path you gave the compiler in the first print (be it test.c, testdir/test.c, or /home/khr/testdir/test.c), but just foo.c for the second.

[davecheney]

Closed as answered.