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

debugger stops in assembler code file #3600

Open
XSven opened this issue Nov 17, 2023 · 9 comments
Open

debugger stops in assembler code file #3600

XSven opened this issue Nov 17, 2023 · 9 comments

Comments

@XSven
Copy link

XSven commented Nov 17, 2023

What did you do? (required: The issue will be closed when not provided)

I have opened a golang source code file. The package is main. I am at a statement line. I am starting the debugger using

GoDebugStart . -url=http://somewhere -n=10 -c=20

The arguments that I have passed are application specific and should not matter. A breakpoint seems to be automatically created at the start of the debugger. I am pressing <F5> (:GoDebugContinue).

What did you expect to happen?

The debugger stops at the given breakpoint.

What happened instead?

When pressing <F5> (:GoDebugContinue) the debugger stops in the file /usr/lib/golang/src/runtime/rt0_linux_amd64.s

This is the vim-go debug output

"main.go" 40L, 641B
vim-go: job command: ['/home/sven.willenbuecher/go/bin/gopls', '-remote=auto']
vim-go: shell command: '/usr/bin/go' 'env' 'GOMOD'
vim-go: shell command: '/usr/bin/go' 'env' 'GOMOD'
vim-go: initializing gopls
vim-go: initialized gopls
vim-go: Finished loading packages.
vim-go: shell command: '/usr/bin/go' 'list'
vim-go: [debug] dispatched
vim-go: job command: ['/home/sven.willenbuecher/go/bin/dlv', 'debug', 'github.com/XSven/hit_project/cmd/hit', '--output', '/tmp/vSahZ1J/8', '--headless', '--api-version', '2', '--listen', '127.0.0.1:8181', '--log', '--log-output', 'debugger,rpc', '--', '-url=http://somewhere', '-n=10', '-c=20']
vim-go: sending to dlv RPCServer.Command
vim-go: sending to dlv RPCServer.ListBreakpoints
vim-go: sending to dlv RPCServer.CreateBreakpoint
vim-go: sending to dlv RPCServer.Command
vim-go: sending to dlv RPCServer.ListBreakpoints
vim-go: sending to dlv RPCServer.LastModified
vim-go: sending to dlv RPCServer.State
vim-go: sending to dlv RPCServer.Stacktrace
vim-go: sending to dlv RPCServer.ListLocalVars
vim-go: sending to dlv RPCServer.ListFunctionArgs
vim-go: sending to dlv RPCServer.ListRegisters
vim-go: current goroutine not found...
vim-go: sending to dlv RPCServer.ListGoroutines
vim-go: No Goroutines Running Now...

Configuration (MUST fill this out):

vim-go version:

1401b57 - 2023-10-02 11:13:19 -0700 (HEAD -> master, origin/master, origin/HEAD) update CHANGELOG.md for #3587 (Billie Cleek <[email protected]>)

vimrc you used to reproduce:

vimrc

Vim version (first three lines from :version):

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 09 2023 00:00:00)
Included patches: 1-2637
Modified by [email protected]

Go version (go version):

go version go1.20.6 linux/amd64

Go environment

go env Output:
GO111MODULE=""
GOARCH="amd64"
GOBIN="/home/sven.willenbuecher/go/bin"
GOCACHE="/home/sven.willenbuecher/.cache/go-build"
GOENV="/home/sven.willenbuecher/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/sven.willenbuecher/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/sven.willenbuecher/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/golang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.6"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/sven.willenbuecher/go/src/github.com/XSven/hit_project/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3323771479=/tmp/go-build -gno-record-gcc-switches"

gopls version

gopls version Output:
golang.org/x/tools/gopls v0.14.2
    golang.org/x/tools/[email protected] h1:sIw6vjZiuQ9S7s0auUUkHlWgsCkKZFWDHmrge8LYsnc=
@bhcleek
Copy link
Collaborator

bhcleek commented Nov 19, 2023

Is your application an http server that's waiting for a request?

@XSven
Copy link
Author

XSven commented Nov 20, 2023

No it is a experiment that teaches me how to use the flag package to parse command-line options and how to coerce strings into other types. This is very basic stuff and no tricky networking.

@bhcleek
Copy link
Collaborator

bhcleek commented Nov 20, 2023

What line is the breakpoint being created on? Can you give me more explicit replication steps?

@XSven
Copy link
Author

XSven commented Nov 22, 2023

I have opened the main.go file and went to line 30. Then I have started the debugger. This already creates the breakpoint at line 30. Then I have pressed <F5>

    1 package main
    2
    3 import (
    4         "fmt"
    5         "os"
    6         "runtime"
    7 )
    8
    9 const (
   10         bannerText = `
   11 __ __ __ ______
   12 /\ \_\ \ /\ \ /\__ _\
   13 \ \ __ \ \ \ \ \/_/\ \/
   14  \ \_\ \_\ \ \_\ \ \_\
   15  \/_/\/_/ \/_/ \/_/
   16 `
   17         usageText = `
   18 Usage:
   19 -url
   20  HTTP server URL to make requests (required)
   21 -n
   22  Number of requests to make
   23 -c
   24  Concurrency level`
   25 )
   26
   27 func banner() string { return bannerText[1:] }
   28 func usage() string  { return usageText[1:] }
   29 func main() {
>  30         f := &flags{
   31                 n: 100,
   32                 c: runtime.NumCPU(),
   33         }
   34         if err := f.parse(); err != nil {
   35                 os.Exit(1)
   36         }
   37         fmt.Println(banner())
   38         fmt.Printf("Making %d requests to %s with a concurrency level of %d.\n",
   39                 f.n, f.url, f.c)
   40 }

@bhcleek
Copy link
Collaborator

bhcleek commented Nov 22, 2023

I'm not able to duplicate the behavior you're seeing, but that could be because I'm using a mac. Can you try again after :GoUpdateBinaries dlv?

What breakpoint are you expecting it to break on? You're already on line 30 and said there was a breakpoint there and it breaks on that. Is your concern that it's breaking after that?

The behavior you're seeing where it breaks in rt0_linux_amd64.s seems like it's yielding to the OS. Can you try :GoDebugContinue instead of using <F5>? I'm wondering if your <F5> is somehow bound to :GoDebugStep or :GoDebugNext.

I'm also interested to know what happens if you :GoDebugNext through each line - on which line does the :GoDebugNext cause the debugger to break in rt0_linux_amd64.s?

Also, can you put a breakpoint on line 34? It's ok to still have the first breakpoint at line 30. If that works, then let's try making the breakpoint on line 34 the only breakpoint.

@XSven
Copy link
Author

XSven commented Nov 26, 2023

  • Updating dlv has changed nothing. It was already the latest one.
  • There was already a breakpoint at line 30 because that was the cursor position when I have started the debugger. I don't know if this is an on purpose of by accident behaviour?!
  • I have used :GoDebugContinue instead of <F5>, the strange behaviour was the same.
  • Amazingly :GoDebugNext is unknown: E492: Not an editor command: GoDebugNext
  • To create an additional breakpoint at line 34 using <F9> was possible, but nothing else has changed: <F5> yields to the OS and :GoDebugNext is still unknown.

By the way my oS is CentOS9-stream and I am running this in a WSL context.

@bhcleek
Copy link
Collaborator

bhcleek commented Nov 27, 2023

Can you debug successfully with the delve CLI?

@XSven
Copy link
Author

XSven commented Nov 27, 2023

I don't know how this works, but I was able to debug successfully using VSCode using the standard Go extension that as far as I know uses delve too. By the way the vim-go debug output that I have provided initially does not tell you anything, correct?

@bhcleek
Copy link
Collaborator

bhcleek commented Dec 6, 2023

By the way the vim-go debug output that I have provided initially does not tell you anything, correct?

That's right. It's useful, but doesn't pinpoint the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants