Czy debugujesz kod C ++ w Vimie? W jaki sposób?

Pytanie jest skierowane do wszystkich osób, które używają Vima do tworzenia aplikacji w C ++.

Był taki okres w moim życiu, który można opisać jako „Nienawidzę Vima !!!” .. „Vim jest fajny!”

Jednak dorastając głównie w środowisku programistycznym firmy Microsoft, przyzwyczaiłem się do tych F5- F11skrótów podczas debugowania kodu, okna obserwacyjnego, stosu wywołań i głównego kodu - wszystko to jest widoczne bez konieczności wpisywania jakichkolwiek poleceń GDB.

Oto pytanie:

Czy używasz Vima również do debugowania? Czy może w tym celu przełączysz się na jakieś IDE? Który?

Dla tych, którzy używają Vima do debugowania kodu: czy istnieją wtyczki do ustawiania punktów przerwania w edytorze, podświetl linię, którą obecnie debugujemy, automatyczną nawigację podczas kroku, wejdź, wyjdź?

Proszę, nie mów mi, że używasz GDB jako wiersza poleceń, widzisz tylko jedną linię, która jest debugowana itp.

W przeciwieństwie do innych odpowiedzi, istnieją co najmniej trzy opcje, które robią dokładnie to, czego potrzebujesz: clewn , pyclewn i vimgdb .

Wszystkie trzy projekty są powiązane. vimgdb jest łatą przeciwko Vimowi i wymaga rekompilacji Vima. clewn to samodzielny program, który komunikuje się z Vimem przez interfejs gniazda Netbeans. Wymaga to zbudowania Vima z +netbeansopcją (tak jest w przypadku ostatnich dystrybucji Linuksa, więc nie powinno to stanowić problemu).

Cytat ze strony internetowej clewn:

Clewn implementuje pełną obsługę GDB w edytorze vim: punkty przerwania, zmienne obserwacyjne, uzupełnianie poleceń gdb, okna asemblera itp.

Myślę, że zdecydowanie powinieneś spróbować.

Strona główna pyclewn przedstawia porównanie trzech projektów.

Kilka miesięcy temu spróbowałem pyclewn. Było to trochę trudne do skonfigurowania, ale wygląda dobrze, choć dobrze i obiecująco. Właśnie wykonałem kilka testów i mogłeś ustawić zakładki itp., Typowe rzeczy, których można oczekiwać od debugera graficznego. Skończyło się na tym, że nie użyłem go z przypadkowych powodów, ale chcę spróbować jeszcze raz.

Vim oficjalnie dodał wbudowany debugger w wersji 8.1, wydanej w maju 2018 r. Funkcja ta była również obecna w niektórych wydaniach wersji 8.0 już w sierpniu 2017 r.

Następujące polecenia vim ładują wtyczkę i uruchamiają debugger.

:packadd termdebug
:Termdebug

To ostatnie polecenie przyjmuje program jako opcjonalny argument lub alternatywnie program można załadować z gdbokna za pomocą filepolecenia.

Po załadowaniu wtyczki gdbmożna jej używać interaktywnie w odpowiednim oknie. Na przykład można ustawić punkty przerwania, przechodzić przez kod i sprawdzać zmienne.

Polecenia Vima mogą być wydawane do interakcji z gdb. Niektóre odpowiednie polecenia obejmują :Step, :Over, :Finish, :Continue, :Stop, :Break, :Clear, i :Evaluate.

Dodatkowo w górnej części okna edytora znajdują się klikalne przyciski do interakcji gdb.

Okno edytora zostanie zaktualizowane, aby odzwierciedlić stan debugowania. Punkty przerwania są oznaczone, >>a bieżąca linia jest podświetlona.

Wbudowana strona pomocy zawiera dokładną dokumentację.

:help terminal-debug

Niedawno napisałem post na blogu przedstawiający przykładową sesję.

https://www.dannyadam.com/blog/2019/05/debugging-in-vim/

Vim to fajny edytor, ale do debugowania używam debuggera (takiego jak GDB).

Ale nie musisz używać GDB w trybie tekstowym; możesz użyć graficznego interfejsu użytkownika, takiego jak KDbg , DDD lub Insight .

Istnieją sposoby na wprowadzenie GDB do Vima (ale wtedy można uzyskać debugowanie tekstowe).

editPolecenie GDB

Otwiera edytor w bieżącej linii za pomocą polecenia:

$EDITOR +<current-line> <current-file>

Domyślnie editorjest to ex, ale vimtakże rozumie +<current-line>format.

Po wyjściu z edytora wracasz do gdb.

Pozwala to na swobodne przeglądanie źródła i jest szczególnie przydatne, jeśli masz ctagsintegrację.

Jest to wbudowana integracja gdb z vimem, wbudowana w jeden sposób dla biedaka: główną brakującą rzeczą jest ustawienie punktów przerwania z Vima.

edit i środek

editdomyślnie nie wyśrodkowuje Vima wokół źródła, więc stworzyłem skrypt Pythona, który to robi: Jak otworzyć bieżący plik w bieżącym wierszu w edytorze tekstu z GDB?

Polecenie punktu przerwania do pomocnika schowka

To polecenie vim kopiuje specyfikator punktu przerwania typu:

b <file-path>:<line-number>

do schowka:

command! Xg :let @+ = 'b ' . expand('%:p') . ':' . line('.')

Następnie możesz po prostu wkleić to do gdb.

To jest vim dla biednych z integracją gdb w celu ułatwienia ustawiania punktów przerwania.

Pulpit nawigacyjny GDB

https://github.com/cyrus-and/gdb-dashboard

Nie ma to nic wspólnego z Vimem, ale jest to lekkie rozwiązanie, które wiele osiąga i może pasować do innych Vimerów.

Inni wspominali o GDB TUI, ale uznałem, że jest zbyt zepsuty i niewystarczająco mocny, aby można go było znieść.

Więc zamiast tego przeniosłem się do rozwiązań opartych na API Pythona, takich jak GDB Dashboard.

Bardziej szczegółowo opisałem użyte i uzasadnienie pod adresem: gdb split view with code

Oto zrzut ekranu tego, co daje:

Zobacz też: /vi/2046/how-can-i-integrate-gdb-with-vim

Zrezygnuj i użyj prawdziwego IDE

Biorąc to wszystko pod uwagę, jest to najlepsze rozwiązanie dla większości ludzi, w tym dla mnie. Większość ludzi po prostu zyska mnóstwo czasu, jeśli będą w stanie przeskakiwać między definicjami w sposób świadomy klasy C ++ bez konieczności wybierania i instalowania kilku różnych wtyczek, co obejmuje również debugowanie krokowe. Od 2020 roku najgorszym dla mnie było Eclipse: https://www.slant.co/topics/1411/~best-ides-for-c-on-linux

Korzystanie z debuggera na poziomie kodu źródłowego to tylko jeden z wielu sposobów diagnozowania nieprawidłowego działania programu i rzadko kiedy go uruchamiam - pomimo faktu, że jest to bardzo łatwe.

Więc dla mnie po prostu nie ma nieodłącznej korzyści z używania edytora tekstu, który jest również debugerem . Zamiast tego używam edytora tekstu, który preferuję - niezależnie od tego, jakiego debuggera wybiorę. W tej chwili do tych celów używam głównie gedit i kdbg , ale te wybory ewoluują niezależnie w czasie.

Aktualizacja 2020: Jest nowa wtyczka vimspector korzystająca z protokołu adaptera debugowania

1. Zainstaluj wtyczkę https://github.com/puremourning/vimspector#installation

2. Konfiguracja (zapis .vimspector.json)

3. Skompiluj z symbolem debugowania g++ cpp.cpp -ggdb -o cpp

4. Naciśnij, F4aby rozpocząć debugowanie

• Zapisz moje .vimspector.jsonw moim katalogu domowym (więc pracuj w dowolnym podkatalogu)

{
"configurations": {
  "Python - Launch": {
    "adapter": "vscode-python",
    "configuration": {
      "name": "Python: Launch current file",
      "type": "python",
      "request": "launch",
      "stopOnEntry": true,
      "stopAtEntry": true,
      "console": "externalTerminal",
      "debugOptions": [],
      "cwd": "${cwd}",
      "program": "${file}"
    }
  },
  "Perl - Launch": {
    "adapter": "vscode-perl-debug",
    "configuration": {
      "name": "Perl: Launch current file",
      "type": "perl",
      "request": "launch",
      "exec": "/usr/bin/env perl",
      "execArgs": [],
      "stopOnEntry": true,
      "stopAtEntry": true,
      "console": "externalTerminal",
      "sessions": "single",
      "debugOptions": [],
      "cwd": "${cwd}",
      "program": "${file}"
    }
  },
  "C - Launch": {
    "adapter": "vscode-cpptools",
    "configuration": {
      "name": "Cpp: Launch current file",
      "type": "cppdbg",
      "request": "launch",
      "externalConsole": true,
      "logging": {
        "engineLogging": true
      },
      "stopOnEntry": true,
      "stopAtEntry": true,
      "debugOptions": [],
      "MIMode": "gdb",
      "cwd": "${cwd}",
      "program": "${fileDirname}/${fileBasenameNoExtension}"
    }
  },
  "Java - Launch": {
    "adapter": "vscode-java",
    "configuration": {
      "name": "Java: Launch current file",
      "request": "launch",
      "mainClass": "com.vimspector.test.TestApplication",
      "sourcePaths": [ "${workspaceRoot}/src/main/java" ],
      "classPaths": [ "${workspaceRoot}/target/classes" ],
      "args": "hello world!",
      "stopOnEntry": true,
      "console": "integratedTerminal"
    }
  }
} }

Niedawno pracowałem przez długi czas nad aplikacją, która wymagała umieszczenia kilku rzeczy na komputerze, na którym była uruchomiona (konfiguracja urządzenia), napisałem kod w vimie, miałem skrypty, które zautomatyzowały budowanie, wysyłając go na serwer , który zawierał skrypt zwracający uwagę na plik wartownika przesłany wraz z plikami binarnymi. Spowoduje to ponowne uruchomienie odpowiednich usług na pudełku, aw innym oknie ssh tail -furuchomiłem plik dziennika.

Krótko mówiąc, w ogóle nie używałem debuggera. Gdybym miał coś nieoczekiwanie umrzeć, po prostu podnosiłem poziomy rejestrowania, robiłem to ponownie i sprawdzałem, jaka była ostatnia rzecz zarejestrowana przed śmiercią, a następnie analizowałem to i naprawiałem problem.

Fajną rzeczą było to, że gdy coś miało problemy w środowisku klienta, po prostu prosiłem o dziennik na poziomie debugowania i mogłem zidentyfikować problem bez konieczności nawet dostępu do ich serwera.

... ale tak, były chwile, kiedy fajnie byłoby mieć debugger.

Wystarczy dodać powyżej:

IMO vim wydaje się być dość lekkim edytorem, a debugowanie ma tendencję do dodawania do wagi. Są na to sposoby, np. Używanie vim7.4 + z

:terminal

i uruchamiając jeden z następujących debuggerów wiersza poleceń (curses). Kilka z nich jest używanych domyślnie w środowiskach IDE, których nigdy nie znałeś. tj. lldb = xcode.

• (c / c ++ / objective c) gdb (debugger gnu) - https://www.gnu.org/software/gdb/
• (c / c ++ / objective c / python etc) remake - http://bashdb.sourceforge.net/remake/
• (java) oracle java debugger - https://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html
• (c / c ++ / objective c) lldb - https://lldb.llvm.org/

oczywiście są bardziej oparte na CLI; @all zachęcamy do proponowania i dodawania do listy. dzięki!