.NET Disassembly 창에서의 F11(Step-into) 키 동작
디버그 환경
- .NET 4.0 Console Application
- Debug Build
- 체크 해제 - Enable the Visual Studio hosting process
- 체크 - Enable unmanaged code debugging
- 심벌 서버 지정 - 마이크로소프트 공용 PDB 심벌 파일 배포 서버
간단한 예제 코드와 함께 .NET Disassembly 창을 들여다 보겠습니다.
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Program pg = new Program();
pg.Test(); <== 이 곳에 BP 를 걸고,
}
void Test()
{
Console.WriteLine("TEST");
}
}
}
위의 예제 코드를 실행하고 F5 디버깅을 시작한 후, BP가 걸린 지점에서 "Ctrl + Alt + D" 키를 눌러 Disassembly 창을 띄워보면 다음과 같은 상황이 됩니다.
보시면 pg.Test 메서드 호출에 해당하는 "call dword ptr ds:[002B3404h]" 명령을 확인할 수 있는데요.
13:
14: pg.Test();
00000039 8B 4D F8 mov ecx,dword ptr [ebp-8]
0000003c 39 09 cmp dword ptr [ecx],ecx
0000003e FF 15 04 34 2B 00 call dword ptr ds:[002B3404h]
00000044 90 nop
15: }
call (E8) 명령과는 달리, call (FF 15) 명령어는 변위값이 아닌 절대 주솟값이 담긴 포인터 주소를 오퍼랜드로 받아서 그 곳으로 이동하는 기능을 합니다. 따라서 이런 경우에는 ds:[002b3404h] 주소에 담긴 값을 절대 주소로 받아서 그 주소로 IP(Instruction Pointer)를 이동하도록 되어 있습니다.
ds:[002b3404h] 값을 확인하기 위해 "Ctrl + D, M" 키를 눌러 메모리 창을 띄운 다음 0x002b3404 주솟값을 확인하니 다음과 같았습니다.
즉, call 명령어에서 F11(Step-into) 키를 누르면 정상적인 경우 0x002bc015라는 주소로 실행이 옮겨가야 합니다.
직접 확인해 볼까요? 그러면, 다음과 같이 "void Test();" 메서드로 진입하는 것을 볼 수 있습니다.
Step-into가 된 것처럼 보입니다. 하지만 "Ctrl + D, R" 키를 눌러 레지스트리 창에서 EIP 레지스터를 확인해 보면 현재의 주소가 0x002bc015로 되어 있지 않다는 것을 알 수 있습니다.
위의 상황은, 아직 JIT 되지 않은 상태의 메서드를 호출하는 것인데 원래대로라면 JIT 컴파일을 해주는 메서드로 진입을 해야 하는데 Visual Studio의 디버거가 이미 JIT 된 이후의 상태로 건너뛰어주는 배려(!)를 해주기 때문에 발생하는 현상입니다.
애석하게도 이러한 배려를 무시할 수 있는 방법은 없고, 정 원한다면 windbg와 같은 별도의 디버거를 이용하셔야 됩니다. 이에 대해서는 다음번 글에서 알아보도록 하겠습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]