02. 디버깅 시작하기

프로젝트가 끝날 때까지는 변동사항을 추적한다.
 : 버전 컨트롤과 버그 트랙킹 SW로 수정된 내용을 파악.


버그 트랙킹 시스템은 코드를 개발하고 있는 과정에 있을 때 리마인더를 간단하게 작성하고 해야 할 일 목록을 유지하게 하는 좋은 도구이다.


디버깅 심벌로 모든 빌드를 만든다.
릴리즈 빌드에서 문제는 디버그 빌드 처럼 call stack을 온전하게 볼 수 없는 것과 같이 때로는 컴파일러가 스택 레지스트리를 최적화 한다는 것

cf) 모든 빌드를 디버깅 심볼 설정



경고를 오류처럼 생각한다.

경고를 무시한다면 예상치 못한 오류를 만나게 될 것이다. warning-leve 4(/W4) -> /WX로 설정하면 모든 경고를 오류처럼 컴파일러가 보고한다.


DLL이 로드된 곳을 안다.

DLL의 기본주소는 알아야 한다. DLL이 특정 주소 로드시 크레쉬에 대한 문제를 찾을 때 좋은 표지판이 된다. DLL의 로드 주소가 겹칠 경우 다른 곳에 로드 하는데, 어디에 로드 됐는지 모른다면 문제가 생길 수 있다.
DLL들의 주소를 바꾸는 것을 리베이싱(rebasing)이라 한다.

리베이싱 방법
1. Platform SDK - REBASE.EXE 이용
REBASE /b 0x600000000 APPLE.DLL
REBASE /b 0x610000000 DUMPLING.DLL
REBASE /b 0x620000000 GINGER.DLL GOOSEBERRIES.DLL
-> GINGER.DLL과 GOOSEBERRIES.DLL 같이 적용 되면, 지정된 시작 주소를 차곡차곡 위치시킨다.

2. dll을 연결할 경우 로드 주소를 명시
http://msdn.microsoft.com/en-us/library/vstudio/w4w1x6a7(v=vs.100).aspx
http://msdn.microsoft.com/ko-kr/library/f7f5138s.aspx


빈번한 빌드
제품 빌드시 릴리즈와 디버그를 동시에 해야한다.
cf) 빌드 스크립터 구성


설치 프로그램을 즉시 만든다.
설치 프로그램을 만들면 테스트도 할 수 있고, 프로그램을 훨씬 빠르게 확인할 수 있따.


[디버그 알아두기!]
/P 파일로 프리프로세스하기
매크로 파일에 문제가 있을 경우, .l 파일을 통해 매크로 확장 정보를 얻을 수 있다.
/X 기본적인 include 무시하기
include환경변수를 무시하고 /l위치에 있는 헤더만 포함
/Z 멤버 정렬 구조화하기
사용 금지. 비 효율
/O1 크기 최소화 하기
MFC의 경우 /O2(속도 최대화) 사용. 하지만 O1이 훨씬 좋다.
/MAP MAP파일 생성
/MAPINFO:LINES MAP파일에 라인 번호 포함
/NODEFAULTLIB 라이브러리 무시하기
@pragma 지시문을 무시함. 이를 통해 링크할 라이브러리를 결정하고 그 순서를 조정할 수 있다.
/PDBTYPE:CON PDB파일 확보하기
/VERBOSE 진행과정 메시지 출력하기



[추가사항]

디버거는 디버깅 대상(debugee) 프로세스의 메모리를 읽고 쓸 수 있으며, 중단점과 같은 디버깅 대상 프로세스가 발생하는 다양한 디버그 이벤트에 반응하는 프로그램이다.

디버거는 일반적으로 디버깅 대상 프로세스를 새로 시작하거나 이미 수행중인 프로세스에 디버거를 연결(attach)하게 된다.

이미지 디버깅 대상 프로세스와 연결이 끝나면 디버거는 DLL 로드, 중단점, 싱글 스텝, 예외 발생과 같은 디버그 이벤트를 기다리며, 이벤트 발생시 처리!

이 반복 루프를 디버거 루프라 한다. 디버깅 대상 프로세스가 OS로 디버그 트랩을 발생시키고, OS는 디버거에게 디버그 이벤트를 발생시킨다.


왜 중단점이 작동하지 않을까? 중단점은 CPU가 인식하는 기계 명령(INT 3H)이 수행될 때 OS 커널로 트랩이 발생하는 HW적 기능을 한다. 커널은 중단점 트랩이 발생될 때 중단점이 발생한 프로세스에 디버거가 연결되 있다면 이벤트를 발생시켜준다. 중단점 설정은 디버깅 대상 프로세스 주소의 명령어를 중단점 명령어로 바꾼다. 그리고 중단점에 의해 제어가 디버거로 넘어오면 원래의 명령으로 원상 복구한다.


중단점은 프로세스상의 주소에 설정된다. 이때 디버그 심볼(debug symbol)을 이용.
디버그 심볼에는 소스코드상에 설정된 중단점을 프로세스의 메모리 중단점으로 매핑하기 위한 정보가 설정되어 있다.


중단점이 발생하지 않는 이유?
- 중단점까지 코드가 수행되지 않았다.
- 디버그 심볼이 디버거에 의해 로드되지 않았다.


디버거가 마땅한 디버그 심볼을 찾지 못했다면 중단점은 활성화 되지 않는다. 디버그 심볼(.PDB(program dtabase))은 코드를 컴파일해 모듈(DLL, EXE)을 생성하는 과정에서 컴파일러에 의해 만들어 진다. 또한 성능 측정을 위해 프로파일링이나 메모리 덤프를 분석하는데도 필수적인 요소이다.


디버그 빌드 - Full(전체표시)
릴리즈 빌드 - pdb-only(코드 최적화 수행 후 디버그 심볼만 생성) 


릴리즈 빌드에서도 디버그 심볼을 설정하는 것이 좋으며, 약간 컴파일 시간이 늘어나긴 하지만 프로그램의 성능을 떨어뜨리지는 않는다. 컴파일러는 디버그 심볼을 생성하면서 고유의 GUID를 할당하고 모듈에도 기록한다. GUID를 통해 심볼파일인가를 확인하는 용도로 사용된다. PDB파일 내에는 변수, 함수, 소스 위치 정보도 포함되어 있다.

디버그 심볼 로드 GUID를 통해 디버그 심볼 파일의 유효성을 확인하고 모듈과 일치하지 않는다면 이 심볼은 무시되고 다른 곳에서 심볼파일을 찾는다. 모듈 디렉토리에서 심볼을 찾지 못하면 디버거는 모듈에 기록돼 있는 디버그 심볼 파일을 찾아 로드하는 작업을 시도한다. 심볼 파일을 찾기 위한 경로를 직접 설정해 줄 수 도 있다.


기본API 심볼 파일의 설치 
[경로] Option - bebugging - symbols - c:\windows\symbols