Your question about how to use IntelliJ, as posed, is better directed to an IntelliJ specific forum.
For the general topic of debugging Go, I'm aware of 4 choices at the moment:
1. use fmt.Printf() to display debug information. This always works. It is currently what most Go programmers do. Yes, it is Old School. But it is also very effective. It is effective even when using Go routines. It's prime advantage is that it always works, it is very portable, and it is quite light weight. It requires no particular IDE.
3. Derek Parker's
https://github.com/derekparker/delve debugger is true go-native debugger. It is pre-1.0 but may still be useful. Although the blog post below discusses gdb, see the comment chain where the author notes the current recommendation of delve instead of gdb:
4. gdb (see
https://golang.org/doc/gdb), while occasionally useful (for things like watchpoints), gdb support is not maintained or offered by the Go authors or project[1]. Single stepping rarely works for very long. Go 1.2.3 had the most working support for gdb. In general I would recommend one of the first three approaches first. Only fall back to gdb if nothing else works, or if you need watchpoints to track down an insidious memory corruption bug. In particular I say reserve GDB as a last resort because GDB will lie to you when you ask it to print the values of local variables in a Go routine, because GDB does not understand Go stacks. (
https://github.com/golang/go/issues/6913, which is likely never going to be fixed; note the "unplanned" tag, and I don't have time to do it myself.) Hence you'll have to combine gdb with Printf (approach #1) anyway. In summary, while sometimes useful, GDB should not be your first choice when debugging Go programs.
GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success.