이번에 커널을 손대면서, vscode를 사용한 이야기를 조금 해볼까 합니다.

리눅스 커널은 처음 2.4시절 부터 만지다가 한동안 만지지 않고 있었는데, 오랜만에 보니 많은 부분이 바뀌기도 했고, 파악할 부분이 많기도 하더군요.

편집기도, 주로 vim + ctags/cscope를 쓰고 있었는데, 예전에 이렇게 써서 이렇게 쓰긴하는데, 왜 굳이 이렇게 귀찮게 써야 하는가 라는 생각이 들기 시작 했습니다.

vim plugin이야 vundle로 쓰고, 자동완성은 clangd plugin 쓰면 되겠지만, 플러그인 설정 부터, 프로젝트 설정까지 하려니깐 귀찮기도 하고, 그렇게 해봐야 원하는 기능이 잘 동작하지도 않습니다.

그게 귀찮으면, source insight 쓰면 되겠지만, 소스 심볼 검색 능력이 썩 맘에 들지도 않아서, 그동안 주력으로 쓰지고 않았습니다.

기존에 쓰는 툴을 가지고 썼을때 맘에 들지 않는 부분여러가지가 있는데, 심볼을 찾는데, 문맥에 상관없이 이름만 같으면 다 찾아줘 버린다는 것도 맘에 안들고, 편집기에서 defconfig를 전혀 이해를 못한다는 것이 제일 맘에 들지 않았습니다. (이것도 youcompleteme를 쓰면 되긴 합니다.)

이게 어떤 상황이냐면, 예를 들어 지금 관심을 가지고 있는 부분이 ftrace인데, 소스를 찬찬히 보고 있습니다. 근데, 컴파일 옵션에서 

CONFIG_FUNCTION_GRAPH_TRACER 을 제거하면 visual studio 같은 IDE라면, 이 config로 감싸져 있는 define 부분은 inactive 되어 dead code임을 알 수 있습니만, vim 이나 source insight 같은 툴은 잘 인식하지도 못합니다. 정확히는 할 수는 있는데 편하지는 않습니다.

잘못된 형식의 이미지 링크입니다.

위의 그림처럼 config를 뺐을때, 에디터에서도 확인이 가능 했으면 좋겠다라는 생각을 하고 있었습니다.

잘못된 형식의 이미지 링크입니다.

요렇게 말이죠... 최신의 IDE라면 당연히 지원되는 기능인데, 안될리가 없다라는 생각에 방법을 찾기 시작 합니다.

다행이도, vscode의 c/c++ plugin이 기본적으로 cmake기반의 프로젝트만 뿐만이 아니라, compile_command.json기반의 프로젝트도 지원하는 것을 알게 되었습니다. 그렇다면, kernel같은 프로젝트도 cmake로 변환하지 않더라도, intellisense에 어떤 compiler flag이나 definition을 각 파일별로 지정 할 수 있다는 것을 의미 하게 됩니다.

요렇게 에디터에서 매크로가 어떻게 확장이 되는지 말이죠. 참고로 KBUILD_MODNAME은 각 모듈별로 다르게 지정 됩니다.

잘못된 형식의 이미지 링크입니다.

내가 이런 생각을 하고 있으면, 누군가 이런 생각을 가지고 있는 사람이 있을꺼다 라고 생각을 했는데, 역시나, github에 helper를 만들어 놓은 사람이 있습니다.

VS Code로 리눅스 커널개발, 갓MS : 클리앙 (clien.net)

이제 python script를 가지고, 설정을 해봤더니, 잘되긴 하는데 뭔가 아쉽습니다.

intellisense가 compile_command와는 뭔가 따로 놉니다. 나는 분명이 compile_command로 프로젝트 설정을 했는데, 자꾸 필요도 없는 소스를 파싱 합니다. 예를 들어 지금 raspberrypi 커널이나 arm64만 보면 되는데, x86이나 sparc도 파싱해댑니다. 이러면서, 메모리 폭발 하고, 심볼 검색도 쓸데 없는게 자꾸 튀어 나옵니다. 게다가 결정적으로 인덱싱을 12시간씩 해대는데, 도저히 참을 수가 없습니다.

그래서, setting을 좀 손보기 시작합니다. file exclude를 지정해서, 쓰지 않는 폴더는 검색하지 않도록 하고, 검색 옵션도 조금 바꿉니다.

이제야 원하는대로 심볼 검색이 되고, 굳이 쓸데 없이 많은 결과물로 눈 필터링 할 필요더 없어 집니다.

이쯤 되고나니깐 조금 욕심이 나서, 빌드, 디버깅 환경도 손을 보게 됩니다.

IDE면 당연히 빌드로 되고, 디버깅이 되야 하는데, 이게 뭔가 싶어서, 빌드와 디버깅도 넣어봅니다.

잘못된 형식의 이미지 링크입니다.

빌드 결과는 터미널 창에 출력이 되고, 워닝과 에러는 문제 pane에 출력이 됩니다. 당연히 소스파일의 위치와 에러 메시지가 함께 출력이 됩니다.

잘못된 형식의 이미지 링크입니다.

디버깅도 launch.json에 지정하면, vscode내에서 gdb/gdb remote를 이용하여, 디버깅이 가능 합니다. kdb는 안해 봤지만, qemu로 돌려봤을땐 매우 잘 되는 것을 확인 했습니다. 전문적인 c/c++ IDE보다는 부족하지만, 그럭저럭 쓸만은 합니다. 제가 써본 gdb frontend 중에서 두번째로 좋습니다.

ctags/cscope의 결과물이 맘에 안들때, 대안으로 써볼수 있는 편집기이기도 하고, 이젠 나이먹어서 키보드 APM이 안나오는 개발자들에게도 좋은 대안이 될 수 있을 것이라 봅니다.