Vim에서 C ++ 코드를 디버깅합니까?

Vim에서 C ++ 코드를 디버깅합니까? 어떻게?

---

문제는 Vim을 사용하여 C ++ 응용 프로그램을 개발하는 모든 사람들에게 있습니다.

내 인생에는 '나는 Vim을 싫어한다 !!!'라고 말할 수있는 기간이 있었다 ... 'Vim is nice!'

그러나 대부분의 Microsoft 개발 십오 일에, 나는 사람들에게 익숙해했습니다 성장하는 데 F5- F11바로 가기를 코드, 시계 창, 호출 스택 및 주요 코드를 디버깅 할 때 - 어떤 GDB 명령을 입력 할 필요없이 모두 볼 수 있습니다.

그래서 여기에 질문이 있습니다 :

디버깅에도 Vim을 사용합니까? 아니면이 목적으로 일부 IDE로 전환합니까? 어느 것?

Vim을 사용하여 코드를 디버깅하는 사람들을 위해 : 편집기에서 중단 점을 설정하는 플러그인이 있습니까? 현재 디버깅중인 줄, 강조 표시하는 단계, 단계 시작, 단계 종료를 강조 표시합니까?

명령 줄로 GDB를 사용한다고 말하지 말고 디버깅 된 한 줄만 참조하십시오.

---

다른 답변과 달리, clewn , pyclewn 및 vimgdb 와 같은 세 가지 옵션 만 있으면 됩니다.

세 프로젝트 모두 관련되어 있습니다. vimgdb 는 Vim에 대한 패치이며 Vim을 다시 컴파일해야합니다. clewn 은 Netbeans 소켓 인터페이스를 통해 Vim과 통신하는 독립형 프로그램입니다. 이를 위해서는 Vim을 +netbeans옵션 으로 빌드해야합니다 (최근 Linux 배포판의 경우 문제가되지 않습니다).

직원의 웹 사이트에서 인용하려면 :

Clewn은 vim 편집기에서 중단 점, 감시 변수, gdb 명령 완료, 어셈블리 창 등 전체 gdb 지원을 구현합니다.

나는 당신이 분명히 그것을 가야한다고 생각합니다.

pyclewn 웹 사이트의 홈페이지는 세 프로젝트 간의 비교를 보여줍니다.

몇 달 전에 나는 pyclewn을 시도했다. 설정하기가 조금 어려웠지만, 유망하고 유망하지만 잘 보입니다. 방금 몇 가지 테스트를 수행했으며 그래픽 디버거에서 기대할 수있는 일반적인 항목 등 북마크를 설정할 수 있습니다. 나는 우연한 이유로 그것을 사용하지 않았지만 다른 시도를하고 싶습니다.

---

Vim은 훌륭한 편집기이지만 디버깅을 위해 디버거 (예 : GDB)를 사용합니다.

그러나 텍스트 모드에서 GDB를 사용할 필요는 없습니다. KDbg , DDD 또는 Insight 와 같은 그래픽 프론트 엔드를 사용할 수 있습니다 .

GDB를 Vim으로 가져 오는 방법이 있지만 텍스트 기반 디버깅을 얻을 수 있습니다.

---

Vim은 2018 년 5 월에 릴리스 된 버전 8.1에 공식적으로 내장 디버거를 추가했습니다.이 기능은 2017 년 8 월 초에 일부 버전 8.0 릴리스에서도 제공되었습니다.

다음 vim 명령은 플러그인을로드하고 디버거를 시작합니다.

:packadd termdebug
:Termdebug

후자의 명령은 프로그램을 선택적 인수로 사용하거나 명령 을 사용하여 gdb창 에서 프로그램을로드 할 수 있습니다 file.

플러그인을로드 gdb하면 해당 창에서 대화식으로 사용할 수 있습니다. 예를 들어 중단 점을 설정하고 코드를 단계별로 실행하며 변수를 검사 할 수 있습니다.

와 상호 작용하기 위해 Vim 명령을 실행할 수 있습니다 gdb. 일부 관련 명령을 포함 :Step, :Over, :Finish, :Continue, :Stop, :Break, :Clear,와 :Evaluate.

또한 편집기 창 상단에는와 상호 작용할 수있는 클릭 가능한 버튼이 있습니다 gdb.

편집기 상태가 디버깅 상태를 반영하여 업데이트됩니다. 중단 점이 표시되고 >>현재 줄이 강조 표시됩니다.

내장 된 도움말 페이지에는 철저한 설명서가 포함되어 있습니다.

:help terminal-debug

최근에 예제 세션을 진행하는 블로그 게시물을 작성했습니다.

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

---

GDB edit명령

다음 명령을 사용하여 현재 줄에서 편집기를 엽니 다.

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

기본값 editor은입니다 ex만 형식 vim도 이해 +<current-line>합니다.

편집기를 종료하면로 돌아갑니다 gdb.

이를 통해 소스를 자유롭게 탐색 할 수 있으며 ctags통합 된 경우 특히 강력합니다 .

이것은 빈약 한 사람의 내장 gdb-vim 통합 방법입니다. 가장 중요한 것은 Vim에서 중단 점을 설정하는 것입니다.

edit 그리고 중심

edit소스를 중심으로 Vim을 중심에 두지 않으므로 파이썬 스크립트를 만들었습니다 .GDB 의 텍스트 편집기에서 현재 줄의 현재 파일을 여는 방법은 무엇입니까?

클립 보드 도우미에 대한 중단 점 명령

이 vim 명령은 다음 유형의 중단 점 지정자를 복사합니다.

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

클립 보드로 :

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

그런 다음에 붙여 넣을 수 있습니다 gdb.

이것은 중단 점을 쉽게 설정하기 위해 gdb에 대한 빈약 한 사람의 vim 통합입니다.

GDB 대시 보드

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

이것은 Vim과 아무 관련이 없지만, 많은 것을 달성하고 다른 Vimmers에 적합한 가벼운 솔루션입니다.

다른 사람들은 GDB TUI에 대해 언급했지만 너무 깨져 견딜 수 없을 정도로 강력하지는 않다는 것을 알았습니다.

So I moved instead to Python API based solutions such as GDB Dashboard.

I have described used and rationale in more detail at: gdb split view with code

Here is a screenshot of what it gives you:

See also: https://vi.stackexchange.com/questions/2046/how-can-i-integrate-gdb-with-vim

---

---

Using a source level debugger is only one of many ways to diagnose faulty program behavior, and I rarely find myself launching one -- despite the fact that it is very easy to do.

So for me, there is simply no inherent advantage to using a text editor that happens to also be a debugger. Instead, I use the text editor that I prefer -- independent of what debugger I choose to use. At the moment, I mostly use gedit and kdbg for these purposes, but these choices evolve independently over time.

---

Having just recently worked on an application for a long time that required a bunch of stuff to be in place on the box it was running (appliance set up), I wrote code in vim, had scripts which automated building, pushing it to a server, which had a script there to notice the sentinel file pushed along with the binaries. This would then restart the appropriate services on the box, and in another ssh window I had a tail -f running on my log file.

Long story short, I didn't use a debugger at all. If I had something die unexpectedly, I'd just bump up logging levels, redo it, and see what was the last thing logged before it died, then analyze that and fix the issue.

The nice thing was that when something had problems in a customer environment, I'd just ask for a Debug-level log and could identify the issue without even requiring access to their server.

... but yes, there were times when it would have been nice to have a debugger.

---

Just to add to above :

IMO vim tends to be quite a light editor and debugging tends to add to the weight. There are ways to do it i.e. using vim7.4+ with

:terminal

and running one of the following commandline (curses) debuggers. A few are used by default for IDEs that you never knew. i.e. lldb = xcode.

• (c/c++/objective c) gdb (gnu debugger) - 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/

obviously there are more cli based ones; @all feel free to suggest and add to list. thanks!

참고URL : https://stackoverflow.com/questions/3536600/do-you-debug-c-code-in-vim-how