Pintos 과정이 마무리 되었다.
진행하면서 큰 도움을 받았던 debug 방법에 대해서 공유해보고자 한다.

Native Debug

0-1. pintos-kaist 프로젝트 진행을 위한 EC2 초기 setting이 완료 되어있어야 한다.

    $ sudo apt update
  	$ sudo apt install -y gcc make qemu-system-x86 python3
  	$ sudo apt install -y gdb

0-2. VSCode에서 open folder > pintos-kaist를 통해 현재 window의 최상위 디렉토리를 pintos-kaist로 만든 후, 아래의 과정을 진행해야 한다.

1. VSCode에서 Native Debug extension을 설치한다.

2. pintos 루트 디렉토리에 .vscode 디렉토리를 만든다.

3. .vscode 디렉토리 안에 launch.json 파일을 생성하고 아래의 내용을 붙여넣는다.
   프로젝트 별로 executable 의 value를 조정해주어야 한다.
   e.g. project2: user programs 에 대하여,
   "executable": "${workspaceRoot}/userprog/build/kernel.o"

{
  "configurations": [
    {
      "type": "gdb",
      "request": "attach",
      "name": "Attach to gdbserver : threads",
      "executable": "${workspaceRoot}/threads/build/kernel.o",
      "target": "localhost:1234",
      "remote": true,
      "cwd": "${workspaceRoot}",
      "valuesFormatting": "parseText"
    }
  ]
}

5. 현재 진행 중인 프로젝트 디렉토리 (e.g. pintos-kaist/threads/ ) 에 pintos를 build 한다. (make)

6. debug 하고 싶은 .c 파일에 브레이크 포인트를 설정한다.

7. 해당 프로젝트의 build 디렉토리 안에서 pintos 테스트를 직접 실행한다. script commands에 --gdb를 반드시 포함시켜야 한다. (e.g. pintos --gdb -- -q run alarm-multiple).

8. 그러면 qemu는 터미널에 다음과 같은 출력을 뱉으면서, 우리가 실행할 gdb가 연결되기를 기다려준다.

   qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]

9. VScode 맨 왼쪽의 "Run and Debug" 탭에 가서 Attach to gdbserver configuration으로 debug를 실행한다.

8. 6번에서 설정한 breakpoint에서 debug를 시작할 수 있다.

다른 debug 방법들

printf()

최고의 근본 debug.
모르겠으면 다 찍어보는 것도 방법이다. 해당 함수가 호출되는지 또한 그 함수 안에서 아무 출력이나 해보면서 확인할 수 있다. (e.g. printf("여기 오니...?"); )

ASSERT()

위에 소개된 두 가지 방법에서는 인간인 우리가 직접 변수들의 값을 확인하면서 오류를 찾는다.
ASSERT() 매크로는 그 확인까지 컴퓨터에게 시켜버리는 방법이다. 간과하기 쉽지만 잘 생각해보면 이렇게 하지 않을 이유가 없다. (내가 직접 확인할 이유가 없다.)

ASSERT()의 인자로 들어가는 식이 true 일 때만 해당 ASSERT()를 통과할 수 있다. 만약 그 값이 false라면 커널은 PANIC에 빠진다. PANIC 메세지에는 검사식, 실행된 파일, 라인 번호, backtrace가 포함된다. 이미 skeleton code에 많은 ASSERT()가 작성되어 있다. 우리가 작성하는 코드에서도 ASSERT()를 적극적으로 활용해 실수를 줄이고 debug를 용이하게 할 수 있다.

C/C++ compiler는 NULL Pointer Exception 같은 정보를 제공해주지 않는다. 따라서 NULL 포인터를 발견하지 못할 경우 해당 포인터 사용시에 매우 이상한 주소(e.g. 0x600)로 Page fault가 발생하면서 kernel이 죽는다. 가슴이 답답해지고 정신이 아득해지는 이러한 상황을, ASSERT()를 활용해 최대한 피할 수 있다.

예를 들면, 어떤 함수 안의 코드를 작성하려고 할 때, 인자로 받은 변수가 당연히 지켜야할 속성들을 함수의 코드가 시작하기 전 ASSERT()를 통해 확인해볼 수 있다. 이렇게 하면 오류의 원인을 거슬러 올라가기가 매우 용이해진다. ASSERT()에 사용된 식이 어떤 이유로 참이 되지 못했는지를 계속 고민하다보면 원인을 찾을 수 있기 때문이다.

건투를 빈다.