dlv problem

[excavador]

Hello,

I am trying to debug my golang program by dlv on OSX.
bazel 0.7.0, rules_go latest.

If I build program by bazel, I receive error

➜ dlv attach 74960
could not attach to pid 74960: decoding dwarf section info at offset 0x0: too short

I found same issue for dlv:
https://github.com/derekparker/delve/issues/79
But static linking does not work on OSX (according to rules_go documentation).

If I build program by

go build

dlv able to attach to my program

How to build golang binaries in bazel on OSX for working with dlv?
Thank you

[jayconrod]

At the moment, I can't reproduce this because dlv is getting killed on my mac (bad Xcode upgrade?).

We're both at a conference this week, so we may be slow to address this.

[excavador]

@jayconrod if your received problem about lldb-server, just run

xcode-select --install

It will solve problem

[jayconrod]

Reproduced. The dlv thing was a linker issue. Downloading a new Go SDK fixed it.

Could you try building with -c dbg? I think we're stripping debug symbols in the default configuration.

[excavador]

➜ bazel build -c dbg //exe/bazel/runner
INFO: Found 1 target...
ERROR: /Users/oleg/pp/src/XXX/exe/bazel/runner/BUILD.bazel:14:1: GoCompile exe/bazel/runner/~debug~runner~/XXX/exe/bazel/runner.a failed (Exit 1).
2017/11/07 19:15:52 missing strict dependencies:
	exe/bazel/runner/main.go: import of gopkg.in/urfave/cli.v2, which is not a direct dependency
	exe/bazel/runner/main.go: import of gopkg.in/yaml.v2, which is not a direct dependency
Target //exe/bazel/runner:runner failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.348s, Critical Path: 0.85s

My build file is following (generated by gazelle)

load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library")

go_library(
    name = "go_default_library",
    srcs = ["main.go"],
    importpath = "XXX/exe/bazel/runner",
    visibility = ["//visibility:private"],
    deps = [
        "//vendor/gopkg.in/urfave/cli.v2:go_default_library",
        "//vendor/gopkg.in/yaml.v2:go_default_library",
    ],
)

go_binary(
    name = "runner",
    importpath = "XXX/exe/bazel/runner",
    library = ":go_default_library",
    visibility = ["//visibility:public"],
)

Probably, it can be fixed easy in build file but is also means we have some problem with gazelle.

[jayconrod]

Not sure if that's a problem with the rules or with Gazelle. Could you post the go_library rule for one of those "missing" imports? I'm wondering if the importpath attribute is wrong.

[excavador]

@jayconrod these rules generated by gazelle by following settings

gazelle(
		name = "gazelle",
		prefix = "XXX",
		external = "vendored",
)

➜ cat vendor/gopkg.in/urfave/cli.v2/BUILD.bazel
load("@io_bazel_rules_go//go:def.bzl", "go_library")

go_library(
    name = "go_default_library",
    srcs = [
        "app.go",
        "args.go",
        "category.go",
        "cli.go",
        "command.go",
        "context.go",
        "errors.go",
        "flag.go",
        "flag_generated.go",
        "funcs.go",
        "help.go",
    ],
    importpath = "gopkg.in/urfave/cli.v2",
    visibility = ["//visibility:public"],
)

➜ cat vendor/gopkg.in/yaml.v2/BUILD.bazel
load("@io_bazel_rules_go//go:def.bzl", "go_library")

go_library(
    name = "go_default_library",
    srcs = [
        "apic.go",
        "decode.go",
        "emitterc.go",
        "encode.go",
        "parserc.go",
        "readerc.go",
        "resolve.go",
        "scannerc.go",
        "sorter.go",
        "writerc.go",
        "yaml.go",
        "yamlh.go",
        "yamlprivateh.go",
    ],
    importpath = "gopkg.in/yaml.v2",
    visibility = ["//visibility:public"],
)

[jayconrod]

Reproduced. This is a problem with the rules, not Gazelle. It only fails with -c dbg. Not sure what's causing that yet.

[excavador]

Still have problem.

➜ dlv attach 48440
could not attach to pid 48440: decoding dwarf section info at offset 0x0: too short

build with "-c dbg" works, but delve can not attach

Can you please reopen bug?