Jak poprawnie debugować plik binarny wygenerowany przez `go test -c` używając GDB?

Question

go test komenda posiada wsparcie dla flagi -c, opisane w następujący sposób:

-c Compile the test binary to pkg.test but do not run it. 
    (Where pkg is the last element of the package's import path.) 

O ile mi zrozumieć, generując plik binarny jak to jest sposób, aby go uruchomić interaktywnie za pomocą GDB. Jednakże, ponieważ binarny test jest tworzone poprzez łączenie plików źródłowych i testów tymczasowo w jakiś/tmp/katalogu, to jest to, co się dzieje, gdy biegnę list w gdb:

Loading Go Runtime support. 
(gdb) list 
42  github.com/<username>/<project>/_test/_testmain.go: No such file or directory. 

Oznacza to, że nie może szczęśliwie skontrolować źródło Go kod w GDB jak jestem przyzwyczajony. Wiem, że możliwe jest wymuszenie pozostania katalogu tymczasowego przez przekazanie flagi -work komendzie go test, ale nadal jest to ogromna trudność, ponieważ plik binarny nie jest tworzony w tym katalogu i tym podobne. Zastanawiałem się, czy ktoś znalazł czyste rozwiązanie tego problemu.

Answer 1

Niestety, wydaje się, że jest to znany problem, który nie zostanie naprawiony. Zobacz tę dyskusję:

https://groups.google.com/forum/#!topic/golang-nuts/nIA09gp3eNU

widziałem dwa rozwiązania tego problemu.

1) utwórz plik .gdbinit za pomocą komendy set-path-path na przekierować gdb do rzeczywistej lokalizacji źródła. Ten plik może być wygenerowany przez narzędzie go, ale istnieje ryzyko, że nadpiszesz niestandardowy plik .gdbinit i powiążesz narzędzie go z gdb, co wydaje się być złym pomysłem: .

2) Zamień ścieżki plików źródłowych w pliku wykonywalnym (które wskazują na/tmp/...) na lokalizację, w której znajdują się na dysku. Jest to proste, jeśli ścieżka rzeczywista jest krótsza niż ścieżka/tmp/.... To prawdopodobnie wymagałoby dodatkowego wsparcia z łącznika kompilatora/ , aby uczynić to rozwiązanie bardziej ogólnym.

To zrodził ten problem w tej sprawie trackera Go Google Code, do których decyzja zakończył się:

https://code.google.com/p/go/issues/detail?id=2881

To jest irytujące, ale jest to najmniej od wielu irytujących możliwości . Zasadniczo narzędzie go nie powinno być zapisywane w źródłowych katalogach , które może nawet nie być zapisywalne, i nie powinno być pozostawiając plików w innym miejscu po jego zakończeniu. Nie ma nic ciekawego w _testmain.go. Osoby testujące z gdb mogą się zepsuć na testowaniu .Main zamiast tego.

Russ Status: Niefortunne

Tak, w skrócie, to jest do bani, a jednocześnie można go obejść i GDB wykonywalny testowy zespół rozwoju jest mało prawdopodobne, aby to tak proste, jak mogłoby być dla Ciebie.

Answer 2

Wciąż jestem nowicjuszem w grze golang, ale na to, jak warto podstawowe debugowanie wydaje się działać.

Komenda list, którą próbujesz uruchomić, może być używana tak długo, jak już znajdujesz się w punkcie przerwania w kodzie. Na przykład:

(gdb) b aws.go:54 
Breakpoint 1 at 0x61841: file /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.go, line 54. 
(gdb) r 
Starting program: /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.test 
[snip: some arnings about BinaryCache] 

Breakpoint 1, github.com/stellar/deliverator/aws.imageIsNewer (latest=0xc2081fe2d0, ami=0xc2081fe3c0, ~r2=false) 
    at /Users/mat/gocode/src/github.com/stellar/deliverator/aws/aws.go:54 
54  layout := "2006-01-02T15:04:05.000Z" 
(gdb) list 
49 func imageIsNewer(latest *ec2.Image, ami *ec2.Image) bool { 
50  if latest == nil { 
51   return true 
52  } 
53 
54  layout := "2006-01-02T15:04:05.000Z" 
55 
56  amiCreationTime, amiErr := time.Parse(layout, *ami.CreationDate) 
57  if amiErr != nil { 
58   panic(amiErr) 

To jest tylko po uruchomieniu następujące w aws podkatalogu mojego projektu:

go test -c 
gdb aws.test 

jako dodatkowe zastrzeżenie, to wydaje się bardzo selektywny o tym, gdzie można umieścić punkty przerwania. Wygląda na to, że musi to być wyrażenie, ale ten wniosek jest tylko eksperymentalny.

Answer 3

Wersja 1.5 została wydana i nadal nie ma oficjalnie usankcjonowanego Go debuggera. Nie odniosłem wielkiego sukcesu, używając GDB do efektywnego debugowania programów Go lub testowych plików binarnych. Jednak miałem sukces przy użyciu zagłębić, nieoficjalnego debugger, który jest jeszcze w trakcie rozwoju: https://github.com/derekparker/delve

aby uruchomić kod testowy w debugger, wystarczy zainstalować zagłębić:

go get -u github.com/derekparker/delve/cmd/dlv

... a następnie uruchomić testy w debuggera z poziomu roboczego:

dlv test

w wierszu debuggera, można jednoetapowy, ustawić punkty przerwania, itd.

Daj temu wir!

Answer 4

Jeśli chcesz używać narzędzi oprócz GDB, sprawdź kod godebug. Aby z niego skorzystać, należy najpierw zainstalować z:

go get github.com/mailgun/godebug 

Następnie wstawić przerwania gdzieś dodając następujące oświadczenie w kodzie:

_ = "breakpoint" 

teraz uruchomić swoje testy z komendą w godebug test.

godebug test 

Obsługuje wiele parametrów z polecenia go test.

-test.bench string 
     regular expression per path component to select benchmarks to run 
    -test.benchmem 
     print memory allocations for benchmarks 
    -test.benchtime duration 
     approximate run time for each benchmark (default 1s) 
    -test.blockprofile string 
     write a goroutine blocking profile to the named file after execution 
    -test.blockprofilerate int 
     if >= 0, calls runtime.SetBlockProfileRate() (default 1) 
    -test.count n 
     run tests and benchmarks n times (default 1) 
    -test.coverprofile string 
     write a coverage profile to the named file after execution 
    -test.cpu string 
     comma-separated list of number of CPUs to use for each test 
    -test.cpuprofile string 
     write a cpu profile to the named file during execution 
    -test.memprofile string 
     write a memory profile to the named file after execution 
    -test.memprofilerate int 
     if >=0, sets runtime.MemProfileRate 
    -test.outputdir string 
     directory in which to write profiles 
    -test.parallel int 
     maximum test parallelism (default 4) 
    -test.run string 
     regular expression to select tests and examples to run 
    -test.short 
     run smaller test suite to save time 
    -test.timeout duration 
     if positive, sets an aggregate time limit for all tests 
    -test.trace string 
     write an execution trace to the named file after execution 
    -test.v 
     verbose: print additional output