dlv version)?go version)?go delve packagenameRepro Steps:
package main
import "fmt"
func main() {
fmt.Println("hello")
}
cd $GOPATH/src/testing
dlv debug testing
dlv debug testing/subfolder
Hey @ramya-rao-a, I can reproduce this, it seems to be a permissions issue, the created binary doesn't have execution permissions and Delve can't run it,
which it reports with the generic error
The name testing is a Go internal package name (in $GOROOT/src/testing) and when go build is called (through dlv debug) with that explicit name it interprets it as its own package and generates it without execussion permissions (not sure why, may be related to the mode used).
When using the sub-folder name testing/subfolder Go knows it's not its own package but another one residing inside $GOPATH and it does give it execution permission. The same can be achieved with dlv debug . (to explicitly indicate to use the CWD) or changing the package name from the generic testing to testing-delve (without needing a sub-package).
This can also be checked directly with the go build command:
mkdir -p $GOPATH/src/testing
cd $GOPATH/src/testing
# Empty directory.
go build -o debug testing
# It doesn't fail, it's building the one from `$GOROOT`.
ls -lah debug
# -rw-rw-r-- [...]
dlv exec ./debug
# ./debug is not executable
# Create a `testing` package here
cat <<EOF > hello.go
package main
import "fmt"
func main() {
fmt.Println("hello")
}
EOF
# Build without using the `testing` name but an explicit reference to the CWD
go build -o debug .
ls -lah debug
# -rwxrwxr-x [...]
dlv exec ./debug
# Type 'help' for list of commands.
# (dlv)
Thanks @schomatis for the detailed answer, I totally forgot about testing being an internal package.
Now I feel all silly for logging this issue.
I tested after renaming the testing folder to something else, and indeed all works as expected.
Sorry for the trouble.
No problem, I actually learned a lot researching this issue :)
Most helpful comment
No problem, I actually learned a lot researching this issue :)