Development tips - minsuk-jang/teamproject GitHub Wiki

• Neovim 코드베이스에서 작업하면서 Neama가 lua와 c로 작업하게하십시오.
• 태그 및 cscope.out

Tweekmonster 고맙습니다!

• 찾아보기 ** Neovim on SourceGraph **
• ** universal-ctags를 설치하십시오. ** "Exuberant ctags"(배포판이 제공하는 전형적인 ctags이진수)는 유지 보수가 되지 않아 Neovim 소스에서 많은 기능을 인식하지 못합니다.
• contrib 폴더는 Neovim을 위한 YouCompleteMe 설정을 포함하고 있습니다.

`make lint'를 사용하여 로컬에서 linter를 실행할 수 있습니다. linting 프로세스는 "https://raw.githubusercontent.com/neovim/doc/ghpages/reports/clint/errors.json" 에서 마스터 linting 오류를 다운로드하고 로컬에서 감지 된 오류를 생략하여 관련 오류만 lint 지역을 변경시킵니다.

한 번에 하나 또는 몇 개의 파일로 작업한다면, 한 번에 하나의 C 파일을 lint 할 수 있습니다.

make clint LINT_FILE="src/nvim/ops.c"

한 번에 모든 파일을 linting 하는것보다 적은 시간이 걸립니다. nvimdev 플러그인이 대신 할 수 있습니다. 테스트를 보완하기 위해서 make testlint를 사용하십시오.

Syntastic을 사용하고 있다면 https://gist.github.com/gilligan/9326904를 사용하여 C 파일에 대한 검사기로 clint.py를 추가 할 수 있습니다.

clint.py는 PATH에 있어야하고 g : syntastic_c_checkers를 수정해야 합니다. 그렇지 않으면 GCC 나 make가 기본값이 됩니다. 자세한 내용은 Syntastic 's documentation를 참조하십시오.

API 메타 데이터를 가져 오는 간단한 셀을 작성하여 Neovim에 명령을 보낼 수 있습니다.

https://github.com/splinterofchaos/neovim-cpp-client-experiment/blob/master/src/vim-shell.cpp

Core dump는 우분투에서는 기본적으로 비활성화되어 있습니다, CentOS 및 기타.

Core dumping을 활성화 하려면 다음을 수행하십시오 :

ulimit -c unlimited

그런 다음 nvim에서 segfault를 재현하면 core을 떠넘깁니다. 일반적으로 이것은 core 파일이 현재 디렉토리에 나타나거나 (/ var / log / apport.log가 어디에 쓰여 졌는지 확인하기 위해) 확인합니다.

core 파일에서 역추적을 얻으려면 다음을 수행하십시오 :

gdb -q -n -ex bt -batch ./build/bin/nvim <path/to/core> > backtrace.txt

-ex가 작동하지 않으면 tee를 사용하여 gdb 세션의 출력을 저장하십시오 :

gdb build/bin/nvim /cores/core.74533 2>&1 | tee backtrace.txt

• Neovim이 멀티 스레드이기 때문에 thread apply all bt가 필요할 수 있습니다. -thread apply all bt full은 더 풍부한 (full) 정보를 보여줍니다.

macOS에서 nvim이 충돌하면 Console.app에서 역추적을 볼 수 있습니다 ( "User Diagnostic Reports" 아래).

open -a Console

macOS에서 코어 덤프 사용을 원할 수도 있습니다. / cores /디렉토리가 존재해야 하고 쓰기 가능해야 합니다.

주어진 하위 문자열과 일치하는 테스트를 실행하려면 TEST_TAG '를 사용하십시오 (예 :it ( "foo", ...)) :

GDB=1 TEST_TAG=foo make functionaltest

그런 다음 다른 터미널에서 다음 작업을 수행합니다 :

gdb build/bin/nvim
target remote localhost:7777

• test / functional / helpers.lua도 참조하십시오.

lldb .deps/usr/bin/luajit -- .deps/usr/bin/busted --lpath="./build/?.lua" test/unit/

1234의 PID로 실행중인 nvim 프로세스에 연결하려면 :

gdb -tui build/bin/nvim 1234

gdb 대화식 프롬프트가 나타납니다. 언제든지 다음 작업을 수행 할 수 있습니다.

• 'foo ()함수에 중단점을 설정하는 break foo`
• ** 다음 단계로 넘어 가기 위한 n **
• 마지막 명령을 반복하기 위한 `'
• 다음 문장으로 들어가기 위한 s
• 계속하기 위한 c
• 현재 함수를 빠져나오기 위한 finish
• 'zub의 값을 출력하는 pzub`
• 현재 위치에서 ** 역추적 ** (콜 스택)을 보기 위한 bt
• 현재 디버깅 맥락에서 소스 파일의 TUI 뷰를 보여주기 위해 CTRL-x CTRL-a 또는 tui enable을 사용하십시오. 이는 gdb "frontend"가 필요 없으므로 매우 유용합니다.
  • 소스 파일보기를 스크롤 하기 위한 <up>과 <down>

• 레코드 전체 insn-number-max 무제한 설정
• continue가 조금 실행됩니다. (최소한 'main()'이 실행될 때까지)
• 기록
• 버그를 유발 한 다음 revert-next,reverse-step 등을 사용하여 디버거를 되감습니다.

여러개의 gdb 클라이언트를 같은 nvim 프로세스에서 실행시키거나 로컬 gdb를 사용하여 원격 nvim 프로세스에 연결할 수 있습니다. gdbserver를 사용하면 단일 프로세스에 연결하여 여러 'gdb` 클라이언트를 제어 할 수 있습니다.

터미널을 열고 nvim에 첨부 된 gdbserver를 다음과 같이 시작하십시오 :

gdbserver :6666 build/bin/nvim 2> gdbserver.log

gdbserver는 이제 포트 6666에서 청취하고 있습니다. 그러면 다른 터미널에서 이 디버깅 세션에 연결해야 합니다 :

gdb build/bin/nvim

gdb를 입력하면 원격 세션에 접속해야 합니다 :

target remote localhost:6666

gdbserver가 TUI를 배경 프로세스로 두는 경우 TUI는 pty (및 SIGTTIN 신호 수신) 및 / 또는 출력 데이터 (SIGTTOU 신호)에서 입력을 읽을 수 없게됩니다. TUI를 특히 중시하는 프로세스로 강제 실행하려면 다음을 추가하십시오.

signal (SIGTTOU, SIG_IGN);
if (!tcsetpgrp(data->input.in_fd, getpid())) {
    perror("tcsetpgrp failed");
}

to tui.c:terminfo_start.

위에서 언급 한 gdbserver 방법을 사용하여 디버깅 세션을 빨리 시작하려면 Custom makefile을 사용하십시오. 이 예제는make debug를 입력 할 때 디버깅 세션을 생성합니다.

.PHONY: dbg-start dbg-attach debug build

build:
	@$(MAKE) -C neovim

dbg-start: build
	@tmux new-window -n 'dbg-neovim' 'sudo gdbserver :6666 ./build/bin/nvim -D'

dbg-attach:
	@tmux new-window -n 'dbg-cgdb' 'cgdb -x gdb_start.sh ./build/bin/nvim'

debug: dbg-start dbg-attach

여기서 gdb_start.sh는 디버거가 시작될 때 호출되는 gdb 명령을 포함합니다. dbg-start 규칙에 의해 시작된 서버에 접속해야 합니다. 예 :

target remote localhost:6666
br main

디버깅 빌드에서 ~ / .nvimlog 로그 파일이 생성됩니다. NVIM_LOG_FILE 환경 변수로 위치를 지정할 수 있습니다.

Clang의 소독 프로그램 (Address Sanitizer : ASan, Undefined Behavior Sanitizer : UBSan, Memory Sanitizer : MSan, Thread Sanitizer : TSan) 중 하나를 사용하여 Neovim을 빌드하고 설치하면 오류가 발생하자마자 바로 잡을 수 있습니다. Valgrind에서 프로그램을 실행하는 것보다 훨씬 빠르기 때문에 일일 편집기로 소독 프로그램을 사용하여 Neovim을 사용할 수 있습니다. ASan의 경우 2 배의 표준 감속이 권장되지는 않지만). Clang 3.4 이상 및 Unix 계열 환경에 접근 할 수 있다고 가정하면 다음 단계를 시작해야 합니다.

• 소독 프로그램 활성화 (ASAN_UBSAN,MSAN,TSAN)로 Neovim 구축 :
  CC=clang-3.4 make CMAKE_EXTRA_FLAGS="-DCLANG_ASAN_UBSAN=ON"
• 선택 사항으로 일반 편집기를 사용하고자 한다면 'make install'을 설치하십시오 :
• ASAN 로그를 저장할 디렉토리를 만듭니다. mkdir -p $ {HOME} /. logs
• 이것을 셀 초기화 스크립트 (예 :.profile)에 추가하십시오 :
  • export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
  • export ASAN_OPTIONS="log_path=${HOME}/.logs/asan" or export ASAN_OPTIONS="detect_leaks=1:log_path=${HOME}/.logs/asan" 메모리 누수를 감지하려면 (조금 느려짐) 다음을 추가하십시오 :
  • export MSAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
  • export TSAN_OPTIONS="external_symbolizer_path=/usr/bin/llvm-symbolizer-3.4 log_path=${HOME}/.logs/tsan"

이제 Neovim은 오류 로그가 $ {HOME} / .log / * san.PID에 쓰여질 때마다 종료해야 합니다.