kuaaan 님 블러그는 정말 보물 창고다.-_-. 릴리즈에서 디버그의 힘든 (테스트 PC가 다를 경우)점에서 여러 유용한 방법들이 있을 줄이야.!!! (우리회사 수석연구원님도 대단하심.ㅠㅠ) VS2010 으로 작업하면서 필요없는데 생기는 이유를 모르는 파일들이 이렇게 유용할줄 몰랐다...VS2010아.............-_-
map파일과 cod파일을 이용하여 여러 방면으로 디버그가 가능하다.
물론 소스단의 Debug보단 편하진 않지만 서버나 산업용 PC에서 테스트를 할 때 VS를 설치 하지 못하는 환경에서 메모리 주소만을 가지고 충분히 Debug가 가능하다.
보통 Release 빌드에서 오류가 발생했을 경우, 개발자에게는 다음과 같이 죽은 주소 정보 정도만 제공된다. Release 빌드한 실행파일로 디버그를 해야 하는데...
죽은 주소가 0x0040101a랜다. 이 주소가 실제 코드의 어느 지점인지를 어떻게 찾을 수 있을까?
특정 메모리 주소를 소스코드와 매핑시키는 데 사용되는 방법이 .map 파일과 .cod 파일이다.
1. map 파일, cod파일이란?
map 파일은... 이런 놈이다.
- Build시에 각 모듈별 exe별로 혹은 dll 별로 1개씩 생성
- 오류가 발생한 주소를 map 파일에서 분석하면 어느 함수의 몇번째 Bytes에서 죽었는지 추적이 가능
- map 파일 생성시 옵션을 주기에 따라 소스코드의 라인 정보나 Export 정보 등도 볼 수 있지만
보통 map파일에서는 어느 함수에서 죽었는지와 주소 Offset까지만 확인하고 더 자세한 분석은
cod파일에서 하게 됨
- Build 시에 cpp 파일마다 1개씩 생성된다. 즉, 해당 exe가 10 개의 cpp로 구성되어 있다면, 1개의 map 파일과 10개의 cod 파일이 생성된다.
- cod 파일에는 cpp 파일 하나마다 생성되는 obj 파일 내에서의 Offset이 기록된다.
- map 파일에서 어느 함수의 127번째 Byte 에서 죽었는지 확인되었을 때, 해당 함수의 127번째 Byte가 소스코드 상에서 어느 위치인지 확인하는데 쓰인다.
2. map 파일 생성하기
map 파일을 얻기 위해서는 Build 시에 map 파일을 생성하도록 Visual Studio에 설정을 해주어야 한다.
Visual Studio 6.0 은 Project Settings 창에서 "Link" 탭을 열고 "General" 카테고리의 "Generate Map File" 체크를 한다.
Visual Studio 2005 의 경우 Project Property 설정 창에서 "Linker > Debugging" 섹션의 "Generate Map File" 부분을 "Yes"로 설정해주면 된다.
체크한 후부터는 빌드 시에 exe 혹은 dll이 생성되는 Output 폴더에 map 파일이 생성된다.
3. cod 파일 생성하기
cod 파일을 생성하기 위해서는...
Visual Studio 6.0 에서는 "Project Setting" 창의 "C/C++"탭에서 "Listing Files" 카테고리를 열어 "Listing File Type"에 cod 파일에 저장할 정보를 선택해주면 된다. 보통 "Assembly, Machine Code, and Source" 를 선택한다.
Visual Studio 2005 에서는 "Project Property" 창에서 "C/C++ > Output files" 를 선택한 후 "Assembler Output" 에 "Assembly, Machine Code and Source Code"를 선택하면 된다.
map 파일을 분석하는 것은 아주 쉽다.
맨 처음의 오류화면 캡쳐에 찍혔던 0x0040101a가 어느 함수에 해당하는지를 먼저 분석해보자.
map 파일의 구조는 다음과 같다.
DebuggingTest
0001:00000000 00000824H .text CODE
0002:00000000 000000a8H .idata$5 DATA
0002:000000a8 00000004H .CRT$XCA DATA
0002:000000ac 00000004H .CRT$XCAA DATA
....
0000:00000000 ___ImageBase 00400000 <linker-defined>
0001:00000000 _main 00401000 f DebuggingTest.obj
0001:0000004e @__security_check_cookie@4 0040104e f MSVCRT:secchk.obj
0001:00000300 _mainCRTStartup 00401300 f MSVCRT:crtexe.obj --> Rva+Base 옆에 표시된 소문자 "f"는 "함수"를 의미한다. f가 표시되지 않는 항목은 Global 변수를 의미한다.
...
0001:000000a8 ___tmainCRTStartup 004010a8 f MSVCRT:crtexe.obj
0001:0000021e _pre_c_init 0040121e f MSVCRT:crtexe.obj
map 파일에서 관심을 가질 곳은 각 함수와 Global 변수들의 주소가 표시된 두번째 섹션이다.
헤더를 보면 네가지 항목으로 구분되어 표시된다.
- Address : 문서에 따라 여러가지 이름으로 표시되지만, 이 항목이 의미하는 것은 Segment와 Offset 으로 표시된 상대주소이다. (Segment 정보는 첫번째 섹션에 나타나 있다.)
- Publics by Value : 함수 혹은 전역변수 등 표시되는 심볼의 이름이다. 이 이름들은 C++ 의 Name Mangling 규칙에 따라 변형되어 표시되지만 대충 알아볼만은 하다. 예를 들어
0002:000000f4 ??_C@_0BD@BPDCHPKM@?$FLFunc2?$FN?5Point?51?5?$AN?6?$AA@ 004020f4 DebuggingTest.obj
- Rva+Base : 문서에 따라 "Linear Address", "Absolute Address"등 여러가지 이름으로 해석되며, 결국 우리가 메모리 상에서 나타나는 주소는 이 주소이다. 우리가 찾고자 하는 주소 0x0040101a 는 여기서 찾아야 한다. Rva+Base 옆에 소문자 "f"가 찍혀있는 항목들은 "함수"라는 의미이며, "f"가 없는 항목들은 변수라는 의미이다.
- Lib:Object : 이 함수가 어느 모듈에 속해있는지를 나타낸다.
map파일 두번째 섹션의 Rva+Base 항목을 처음부터 뒤지면서 우리가 찾고자 하는 주소(0x0040101a)를 처음으로 넘어서는 지점을 찾는다.
Address Publics by Value Rva+Base Lib:Object
0000:00000000 ___ImageBase 00400000 <linker-defined>
0001:00000000 _main 00401000 f DebuggingTest.obj --> 여기까지는 넘어서지 않았다.
0001:0000004e @__security_check_cookie@4 0040104e f MSVCRT:secchk.obj --> 넘어섰다.
0001:00000300 _mainCRTStartup 00401300 f MSVCRT:crtexe.obj
...
위의 map파일 상에서 0x0040101a라는 주소는 _main 함수의 시작지점보다는 뒤에 있고, @__security_check_cookie@4 함수의 시작지점 보다는 앞에 있음을 알 수 있다. 따라서 0x0040101a는 _main 함수 중의 한 지점 임을 알 수 있다.
그렇다면 0x0040101a는 _main함수의 어느 부분일까? 위에서 언급한 바와 같이 .map파일로는 정확한 코드는 집어낼 수 없지만 함수와 함수 시작지점으로부터의 Offset을 계산할 수 있다. 이 Offset값을 .cod 파일에서 뒤지면 Exception이 발생한 코드를 찾아낼 수 있다.
= 0x0040101a - 0x00401000 = 0x001a
따라서 Exception이 발생한 지점은 main 함수의 시작지점으로부터 0x001a Bytes 떨어진 지점임을 알 수 있다.
이제 main함수가 정의된 cpp 파일의 cod 파일을 분석해 main함수의 0x001a번째 Bytes 에 어떤 코드가 있는지 확인해보자.
cod 파일은 다음과 같이 생겼다.
PUBLIC _main
; Function compile flags: /Ogtpy
; File d:\src\test_code\debuggingtest\debuggingtest\debuggingtest.cpp
; COMDAT _main
_TEXT SEGMENT
_argc$ = 8 ; size = 4 --> 함수의 파라메터 정의
_argv$ = 12 ; size = 4
_main PROC ; COMDAT --> _main 함수 시작
이부분에 해당하는 어셈코드가 밑에 파란색 부분이다....
00 mov esi, DWORD PTR __imp__printf --> 위의 기계어 한줄이 어셈으로는 이렇게 세줄이 된다.
00007 68 00 00 00 00 push OFFSET ??_C@_0BB@CCJLHOBA@?$FLMain?$FN?5Point?51?$AN?6?$AA@
0000c ff d6 call esi
; 18 : printf ("[Main] Point 2\r\n");
00013 ff d6 call esi
; 20 : *(LPINT)NULL = 0; // Exception!!
; 21 :
; 22 : printf ("[Main] Point 3\r\n");
0001a c7 05 00 00 00 --> 찾았다!!!
00 00 00 00 00 mov DWORD PTR ds:0, 0
00024 ff d6 call esi
00026 83 c4 0c add esp, 12 ; 0000000cH
0002b 5e pop esi
_main ENDP
_TEXT ENDS
END
위와 같이 Exception이 발생한 지점을 C++ 코드 상에서 정확하게 집어낼 수 있다.
한가지 주의할 것은 위의 COD 파일 내에서의 "0001a" 이라는 offset은 main함수 내에서의 offset이 아니라 main.cpp이 build된 main.obj 내에서의 offset이라는 점이다. 단지 이 경우는 main()의 시작 offset이 main.obj 의 시작 지점과 동일했기 때문에 우연히 같은 주소가 나타났을 뿐이다.
예를 들어 main()함수의 첫번째 코드 주소가 0x01000 이었다고 하면, main()함수의 0x00001a offset 지점의 위치는 다음과 같이 계산된다.
즉, COD 파일 내에서 0x0101a 를 찾으면 된다.
6. DLL 안에서 발생한 Exception 추적하기
위와 같이 exception이 exe 에서 발생했을 때는 exe의 map파일을 이용해 추적하면 된다.
그렇다면... 만약 exception이 dll 안에서 발생했을 때는?? 당근 dll의 map 파일을 사용해야 하긴 하는데... 여기에 약간의 문제가 생긴다.
죽은 화면은 아까와 비슷하지만... 0x003c103e 라는 주소 부터가 이미 exe것이 아님을 느낄 수 있다. (exe는 0x00400000부터 시작하니까!!) 당근 저 주소를 가지고 exe의 map 파일을 뒤져봤자 찾아지지 않는다.
그렇다면 Exception이 발생한 TestDll.dll의 map파일을 살짝 살펴보자.
TestDll
0001:00000000 00000838H .text CODE
0002:00000000 00000084H .idata$5 DATA
...
map 파일의 시작부분을 보면 "Preferred load address is 10000000"이라고 되어 있다. 이 말인 즉슨, 이 DLL이 선호하는 Load Address가 0x10000000 이라는 의미 외에도 "이 map파일은 Dll의 Base Address가 0x10000000 이라고 가정하고 (즉, 0x10000000에 로드되었다고 가정하고) 작성되었다"는 의미로 해석해야 한다.
따라서, Dll의 Load Address가 0x10000000이 아닐 때는 (99.9% 아닐것이다.) 이를 보정해서 map파일을 해석해주어야 한다.
다음은 Dll을 Load하는 코드의 일부이다.
{
printf ("[Main] Fail to Load DLL!\r\n");
return FALSE;
}
printf ("[Main] Load DLL Address : 0x%08p\r\n", hDll);
위의 LoadLibrary했을 때 얻어오는 리턴값 HMODULE 핸들이 로드된 Dll의 Base Address 가 된다.
프로세스에 로드된 모든 Dll 의 Base Address를 얻어오는 방법은 EnumProcessModules API를 사용하는 방법과 프로세스 이미지의 PE 헤더를 분석하는 방법이 있는데 이 방법은 다음에 기회되면... ^^
위의 샘플 코드에서는 Dll의 Base Address 가 0x003C0000 였다.
그러면 dll의 map파일은 다음과 같이 분석할 수 있다.
2) Dll의 Base Addr : 0x003C0000
3) Exception이 발생한 위치의 Dll 내에서의 Offset : 0x003c103e - 0x003C0000 = 0x103e
4) Dll의 Base Addr이 0x10000000 이라고 가정했을 때의 Exception Address : 0x10000000 + 0x103e = 0x1000103e
따라서... dll의 map 파일에서 0x1000103e 를 찾으면 된다.
7. map 파일과 cod 파일의 관리에 관하여
위와 같이 Exception이 발생했을 때 해당 exe 의 정확한 map파일과 cod 파일만 가지고 있다면 거의 정확히 Exception이 발생한 위치를 발생한 위치를 집어낼 수 있다. 문제는 모든 실행파일의 버젼이 바뀔때마다 해당 버젼의 map 파일과 cod 파일을 백업받고 보관한다는 것이 상당히 귀찮다는 것이다. 이럴 때 Visual Studio의 "Post Build Script" 기능을 사용하여 매번 Build할 때마다 map 파일과 cod 파일을 자동으로 백업받도록 설정할 수 있다.
VS6.0에서는 "Project Settines"창의 "PostBuild" 탭에, VS2005에서는 Build Events > Post-Build Event 에 설정한다. 스크립트의 내용은 Dos 명령어 혹은 배치파일 형태이면 되며, 경로나 파일명 등에 Visual Studio에서 제공하는 매크로를 사용할 수 있다.
<참고자료>
Finding crash information using the MAP file By Wouter Dhondt
출처 : (kuaaan) http://kuaaan.tistory.com/102
