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

Jump to bottom

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

Closed
nd opened this issue Jul 23, 2020 · 10 comments
Closed

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

nd opened this issue Jul 23, 2020 · 10 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@nd
Copy link
Contributor

nd commented Jul 23, 2020

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
@nd nd mentioned this issue Jul 23, 2020
Closed
@davecheney
Copy link
Contributor

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
Copy link
Contributor

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

@nd
Copy link
Contributor Author

nd commented Jul 23, 2020

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

nd commented Jul 24, 2020

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
Copy link
Contributor

davecheney commented Jul 24, 2020 •
edited

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

@cagedmantis cagedmantis changed the title Compiler doesn't expand paths specified in the //line directive cmd/compile: Compiler doesn't expand paths specified in the //line directive Jul 27, 2020
@cagedmantis
Copy link
Contributor

/cc @randall77 @griesemer

@cagedmantis cagedmantis added this to the Backlog milestone Jul 27, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 27, 2020
@randall77
Copy link
Contributor

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
Copy link
Contributor

Closed as answered.

@golang golang locked and limited conversation to collaborators Aug 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
6 participants
@davecheney @nd @cagedmantis @aarzilli @randall77 @gopherbot