Debugging Go Code with GDB. Introduction

The following applies to the gc toolkit. Gccgo has built-in gdb support. In addition to this review, you can consult the GDB manual .

When you compile and link your Go programs using gc tools in Linux, Mac OS X, or FreeBSD, the resulting binary files contain DWARFv3 debugging information that the latest version of GDB debugger (> 7.1) can use to examine the live process or dump.

To omit debug information, pass the '-s' flag to the linker (for example, go build -ldflags "-s" prog.go ).
')
The code generated by the gc compiler includes embedding function calls and registering variables. These optimizations can sometimes make debugging using GDB more difficult. To disable them during debugging, pass the -gcflags "-N -l" flag to the go command, which is used to build debugged code.

Common operations

• Display the file and line number of the code, set a breakpoint and disassemble:
  

   (gdb) list (gdb) list line (gdb) list file.go:line (gdb) break line (gdb) break file.go:line (gdb) disas 

  
  
• Show traces and promoted stack frames:
  

   (gdb) bt (gdb) frame n 

  
  
• Show the name, type, and location in the stack frame of local variables, arguments, and return values:
  

   (gdb) info locals (gdb) info args (gdb) p variable (gdb) whatis variable 

  
  
• Show name, type and location of global variables:
  

   (gdb) info variables regexp 

  
  

Go extensions

The new extension mechanism GDB allows you to load extension scripts for a given binary file. The toolkit uses this fact to expand GDB with a small number of commands that allow you to explore the insides of executable code (such as gorutiny) and beautifully display the built-in types of dictionaries, slices and channels.

• Beautiful display of strings, slices, dictionaries, channels or interfaces:
  

   (gdb) p var 

  
  
• The $ len () and $ cap () functions for strings, slices, and dictionaries:
  

   (gdb) p $len(var) 

  
  
• The function to bring interfaces to their dynamic types:
  

   (gdb) p $dtype(var) (gdb) iface var 

  
  Known issue: GDB cannot automatically find the dynamic type of the interface value if its name is long and short (annoying when the stack trace is displayed, instead of a beautiful display, we get a short type name and a pointer).
  
  
• Research gorutin:
  

   (gdb) info goroutines (gdb) goroutine n cmd (gdb) help goroutine 

  
  For example:
  

   (gdb) goroutine 12 bt 

  
  

If you want to know how the extension script works or you want to expand it, look at src / pkg / runtime / runtime-gdb.py in the Go source directory. It depends on several special magic types ( hash<T,U> ) and variables ( runtime.m and runtime.g ), the description of which in the DWARF code is provided by the linker ( src / cmd / ld / dwarf.c ).

If you are interested in what debugging information looks like, run ' objdump -W 6.out ' and review the .debug_* sections.

Known Issues

1. A beautiful display of strings works only for the type of the string, and not for the types inherited from it.
2. Type information is missing for parts of the runtime library written in C.
3. GDB does not understand the definition of Go names and treats "fmt.Print" as an unstructured literal with "." which should be placed in quotes. This is even more true of the pkg.(*MyType).Meth .
4. All global variables are ranked in the main package.