디버그 심볼 파일

디버그 심볼 파일이란 실행 파일을 빌드할 때 생성되는 디버그용 정보 파일을 말한다.

보통 심볼 파일이라고 하거나 그냥 심볼이라고 부르기도 한다 디버그 심볼파일에 포함되는 디버그 정보란 실행 파일 안에 존재하는 함수나 변수들의 이름과 위치, 소스 파일, 소스 라인 정보다, 비주얼 스튜디오나 WinDbg같은 디버거는 이 심볼 파일을 이용해 소스 라인 디버깅을 가능하게 한다.

 

 비주얼 스튜디오에서 foo.exe를 빌드한다고 가정했을 때 Debug 빌드를 하면 기본적으로 foo.pdb가 함께 생성된다. 비주얼 스튜디오에서 디버깅을 하려면 필요한 정보 파일이므로 스튜디오에서 Release 빌드를 하면 기본적으로 foo.pdb는 생성되지 않는다. 비주얼 스튜디오에서 Release 빌드로 디버깅할 수 없는 이유가 여기에 있다.

 

WinDbg를 사용하는 데 있어서 심볼 파일 로드는 기본 중의 기본이다. 심볼 없이 디버깅을 한다는 것은 불가능한 일은 아니지만 일반인에게는 불가능에 가까운 일이라고 보면 된다. 심볼없이 디버깅 하는 것은 처음 가는 오지를 무작정 탐험하는 것과 비슷한 상황으로 볼 수 있다. 어디로 가야 할지 여기가 어디인지조차 파악하기 어려운 지경이라고 봐야한다. 

이런 상황에서 심볼은 지도와 같은 역할을 한다. 현재의 위치와 상황을 알 수 있으며, 더 나아가 주변에 위치한 것들이 어떤 것들이고, 어디로 가봐야 좋은지에 대한 객관적인 정보를 제공한다. 그러므로 마이크로소프트에서는 운영체제에 대한 심볼 파일들을 이미 오래전부터 공개해 왔으며 사용자들이 윈도우에서 발생하는 문제들을 좀더 쉽게 풀어나가도록 적극적으로 지원하고 있다.

 

마이크로소프트는 윈도우 버전마다 심볼 패키지를 각기 묶어 홈페이지에서 제공했었다. 하지만 이 방법은 용량이 큰 심볼 패키지를 일일히 다운로드해야 하고 디버깅 대상이 될 운영체제에 정확히 맞는 심볼을 항상 구해야 한다는 단점이 있다. 게다가 요즘 보안 패치가 너무 자주 일어나므로 윈도우 RTM(Release to Manufacturing)이나 SP(Service Pack)에 포함되지 않고 그때그때 업데이트되는 무수하게 많은 패치 버전들이 존재한다. 심볼 패키지를 사용하면 이런 버전들의 심볼을 구할 수 없는 문제가 있다.

 

따라서 현재 심볼을 구하고 로드하는 가장 좋은 방법은 웹 심볼을 이용하는 것이다. 마이크로소프트는 웹 심볼 서버라는 웹사이트를 구축해 마이크로소프트가 제작한 모든 운영체제 버전에 대한 심볼을 제공한다. WinDbg를 사용해 웹 심볼을 사용하게 설정하면 WinDbg에서 디버깅 중인 윈도우의 정보와 파일 정보를 심볼 서버로 보내고 심볼 서버는 해당윈도우 버전에 맞는 심볼 파일만을 WinDbg로 다운로드해줘서 정확한 심볼 파일을 사용할 수 있게 한다. 웹 심볼의 가장 큰 장점은 WinDbg를 사용하는 사람이 굳이 윈도우 버전을 알고 있지 않더라도 스스로 알아서 맞는 버전을 찾아 준다는 점과 윈도우를 구성하는 모든 파일에 대한 심볼 파일을 한꺼번에 다운로드하지 않는 다는 점이다.

 

첫 번째 장점의 의미는 디버깅 중에 ntdll.dll의 정보가 필요한 상황이 발생한다면 윈도우 10을 디버깅할 때는 윈도우 10에 포함된 ntdll.dll의 심볼 파일이 다운로드되고, 윈도우 7 을 디버깅 할때는 윈도우 7 용 ntdll.dll의 심볼 파일이 다운로드 된다는 의미이다. 사용자가 윈도우 버전을 지시하지 않더라도 심볼 서버는 정확한 버전을 사용하도록 해준다.

 

두 번째 장점은 ntdll.dll의 정보가 필요할 때 ntdll.dll만 다운로드할 뿐 kernel32.dll 같은 다른파일들의 심볼 파일은 다운로드 하지 않는 다는 점이다. kernel32.dll의 심볼 파일은 디버깅 중에 kernel32dll 정보를 보게 돼 심볼 파일이 필요해지는 첫 번째 시점에 다운로드한다. 이것을 지연된 심볼 로딩(Deferred Symbol Loading 또는 Lazy Symbol Loading)이라 하는데, 이것으로 인해 윈도우 구성 파일이 그렇게 많음에도 불구하고 적절한 심볼 파일을 적절한 시간에 다운로드해 편리하게 사용할 수 있다. 또한 다운로드한 심볼 파일들은 하드 디스크의 지정된 영역에 저장되므로 다음번에 사용할 때는 이곳을 먼저 검색한 후에 웹심볼을 사용하므로 매번 인터넷에 접속하는 것은 아니라는 점도 알아두기 바란다. 하지만 여전히 가끔은 심볼 파일들은 다운로드하느라고 WinDbg가 '응답 없음' 처럼 보일 때도 있다. 그리고 가끔 웹 심볼이 정상적으로 보이지 않을 때가 있는데, 이는 하드 디스크에 저장돼 있는 파일이 손상된 경우일 수 있다. 이럴 떄는 하드 디스크에 있는 해당 심볼 파일을 삭제한 후 다시 받으면 해결된다.

 

마이크로소프트에서 심볼 파일을 제공하는 것처럼 자신이 만드는 제품들도 심볼 파일을 제공 해야한다.

회사 외부로는 제공하지 않더라도 최소한 회사 내부에서는 개발, 테스트, 기술지원에 사용할 수 있게 심볼 파일이 준비돼 있어야 한다. 이것은 그냥 되는 것이 아니라 제품을 개발할 때 바이너리 파일들과 일치하는 심볼 파일들을 늘 ㅅ애성해야 한다는 의미다. 심볼 파일은 pdb확장자를 가지는데, 마이크로소프트 개발 도구에서 기본적으로 pdb파일은 디버기 빌드(Debug Build)에서만 생성되고 릴리즈 빌드(Release Build)에서 생성되지 않을는다 그러므로 많은 회사들이 소프트웨어 제품을 판매하면서 심볼 파일은 준비하지 않고 제품을 출시하는 경우가 많다. 사실 이것은 릴리즈 빌드에서 심볼 파일이 기본적으로 생성되지 않기에 발생하는 문제가 아니라 심볼을 이용한 디버깅이 얼마나 효율적인지 개념을 모르고 있어서 발생하는 현상이다. 이런 회사는 출시한 소프트웨어에 문제가 발생해도 정확한 원인을 파악해 문제를 해결하기보다는 감각이가 추정에 의지해 문제를 해결하고 있을 가능성이 높다. 이런 식으로는 정확히 문제의 원인을 찾아서 수정하기가 어려워 비용과 시간도 그만큼 낭비된다 심볼파일을 사용해서 정확한 디버깅을 하는 것이 소프트웨어 제품의 안정성과 생산성을 얼마나 높여주는지를 이해한다면 당장 심볼 파일을 준비 할 수 밖에 없을 것이다. 앞서 설명했지만 마이크로 소프트는 이미 수년 전부터 릴리즈버전에 대한 심볼을 기본적으로 활용하고 있으며 외부로 공개해 윈도우 응용프로그램 개발사들을 간접 지원하고 있다.

릴리즈 빌드에서 심볼 파일을 생성하려면 컴파일 옵션을 수정해야 한다.

당연히 모든 소프트웨어 개발 프로젝트는 시작할 때 부터 릴리즈 빌드에서 심볼 파일을 생성하게 빌드 설정을 만들어 놓아야 한다.