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?

[excavador]

@ianthehat @jayconrod can you please re-open bug?
Original problem still actual

[ianthehat]

I can't reproduce the problem, I can correctly debug a binary built using -c dbg on osx using dlv exec and list all the symbols now.

[excavador]

@ianthehat interesting. After clean --expunge problem was solved.

Sorry for stupid question, but what the difference between plain build and build with "-c dbg"?
Just strip debug symbol?

Would be ok if I add "build -c dbg" to tools/bazel.rc or some unobvious consequences exist?

[excavador]

@ianthehat @jayconrod by the way, documentation about "-c" option missed:
https://docs.bazel.build/versions/master/command-line-reference.html#build

What does this option mean?

[ianthehat]

-c is the short form of --compilation_mode

in debug mode we disable stripping and also inlining (you can control just stripping with --strip instead)
I would not recommend putting it in tools/bazel.rc. It would work, but that file is intended to be checked in, and you probably don't want to force everyone to build slow large binaries.

Note that you can also use --run_under

bazel-run -c dbg --run_under='dlv exec' //my:binary

where bazel-run is the bazel run wrapper script you can get using

curl --output bazel-run https://raw.githubusercontent.com/bazelbuild/bazel/master/scripts/bazel-run.sh && chmod +x bazel-run

and that's nice and easy to alias to bazel-dlv or something

[excavador]

I would not recommend putting it in tools/bazel.rc. It would work, but that file is intended to be checked in, and you probably don't want to force everyone to build slow large binaries.
Otherwise I would not able to analyze core-dumps from production installation

[ianthehat]

I would strongly recommend that for building production binaries you are using --bazelrc and --nomaster_bazelrc and controlling every argument explicitly on your release builder bots, not relying on the default bazel rc files.

If you are willing to bear the cost of debug binaries for the benefits of debuggable servers, then that is fine, and you should add -c dbg to your release building scripts.

[excavador]

Thank you!