Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 3개 있습니다.)
(시리즈 글이 10개 있습니다.)
.NET Framework: 202. CLR JIT 컴파일러가 생성한 기계어 코드 확인하는 방법
; https://www.sysnet.pe.kr/2/0/975

.NET Framework: 210. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후
; https://www.sysnet.pe.kr/2/0/1023

.NET Framework: 395. C# - 프로퍼티로 정의하면 필드보다 느릴까요?
; https://www.sysnet.pe.kr/2/0/1545

.NET Framework: 396. C# - 프로퍼티로 정의하면 필드보다 느릴까요? - windbg / ollydbg
; https://www.sysnet.pe.kr/2/0/1546

.NET Framework: 542. 닷넷 - 특정 클래스가 로드되었는지 여부를 알 수 있을까?
; https://www.sysnet.pe.kr/2/0/10888

.NET Framework: 545. 닷넷 - 특정 클래스가 로드되었는지 여부를 알 수 있을까? - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/10893

디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/12133

.NET Framework: 2015. C# - 인라인 메서드(inline methods)
; https://www.sysnet.pe.kr/2/0/13063

.NET Framework: 2016. C# - JIT 컴파일러의 인라인 메서드 처리 유무
; https://www.sysnet.pe.kr/2/0/13064

닷넷: 2132. C# - sealed 클래스의 메서드를 callback 호출했을 때 인라인 처리가 될까요?
; https://www.sysnet.pe.kr/2/0/13391





이번 글은 지난번 이야기에서 이어서 진행됩니다.

.NET Disassembly 창에서의 F11(Step-into) 키 동작
; https://www.sysnet.pe.kr/2/0/1022

이전 글에서 살펴본 내용은, .NET 메서드가 JIT 컴파일 되기 전과 후의 변화를 확인하려는 의도에서 시도해 본 것인데 아쉽게도 .NET Disassembly 창에서는 이에 대해 직접적인 확인이 불가능했습니다.

이번에는 windbg로 시도해 볼텐데, 어떻게 확인이 되는지 기록을 남겨봅니다.




우선, 메서드에 대해 JIT 컴파일 전과 후를 windbg에서 쉽게 접근하도록 다음과 같은 간단한 예제 코드를 작성해 봅니다.

class Program
{
    static void Main(string[] args)
    {
        Program pg = new Program();

        Console.ReadLine();
        pg.Test();
        Console.ReadLine();
        pg.Test();
    }

    void Test()
    {
        Console.WriteLine("TEST");
    }
}

프로젝트 환경은 다음과 같이 구성되어 있고,

  • .NET 4.0 Console Application
  • Debug Build
  • 체크 해제 - Enable the Visual Studio hosting process
  • 체크 - Enable unmanaged code debugging
  • 심벌 서버 지정 - 마이크로소프트 공용 PDB 심벌 파일 배포 서버

Visual Studio에서 "Ctrl + F5 (Start Without Debugging)" 단축키로 실행시킨 후, windbg를 이용해서 연결하고 sos.dll을 로드합니다.

0:005> .loadby sos clr

이제, 닷넷 메서드를 호출하는 코드에 BP를 걸어야 하는데요. 이게 좀 애매합니다. ^^ 예를 들어, 다음과 같이 !bpmd를 사용한다면 어떻게 될까요?

0:005> !bpmd ConsoleApplication1 ConsoleApplication1.Program.Test
Found 1 methods in module 002a2e9c...
MethodDesc = 002a33fc
Adding pending breakpoints...

!bpmd는 sos.dll의 확장명령어로 ".NET"에 대한 배려가 되어 있어서 실제로 이 상태에서 'g' 키를 눌러서 진행하면 아래와 같이 해당 메서드를 JIT 컴파일 시킨 후에야 메서드의 진입점에서 실행을 멈추게 해줍니다. (이전 글의 .NET Disassembly 창에서의 배려와 유사하죠.)

0:005> g
(15fc.2540): CLR notification exception - code e0444143 (first chance)
JITTED ConsoleApplication1!ConsoleApplication1.Program.Test()
Setting breakpoint: bp 009A7A20 [ConsoleApplication1.Program.Test()]
Breakpoint 0 hit
eax=002a33fc ebx=00000000 ecx=02e7bbac edx=00000000 esi=0049ca68 edi=001bf220
eip=009a7a20 esp=001bf1e4 ebp=001bf1f4 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
009a7a20 55              push    ebp

즉, 실제로 BP를 걸어서 확인해야 하는 지점은 Main 메서드의 기계어 코드에서 pg.Test(); 메서드를 호출하는 곳이어야 합니다.

이를 위해서 우선 Main 함수의 실제 주소를 알아내야 합니다.

0:008> !name2ee ConsoleApplication1.exe!ConsoleApplication1.Program.Main
Module:      00132e9c
Assembly:    ConsoleApplication1.exe
Token:       06000001
MethodDesc:  001333f0
Name:        ConsoleApplication1.Program.Main(System.String[])
JITTED Code Address: 00762670

그다음 !u(Unassemble) 명령어로 pg.Test 호출을 하는 주소를 알아냅니다.

0:008> !u 00762670
Normal JIT generated code
ConsoleApplication1.Program.Main(System.String[])
Begin 00762670, size 64
*** WARNING: Unable to verify checksum for D:\...[생략]...\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe

D:\...[생략]...\ConsoleApplication1\Program.cs @ 11:
>>> 00762670 55              push    ebp

...[생략]...

D:\...[생략]...\ConsoleApplication1\Program.cs @ 15:
007626b0 8b4df8          mov     ecx,dword ptr [ebp-8]
007626b3 3909            cmp     dword ptr [ecx],ecx
007626b5 ff1504341300    call    dword ptr ds:[133404h] (ConsoleApplication1.Program.Test(), mdToken: 06000002)
007626bb 90              nop

...[생략]...
007626cf 90              nop
007626d0 8be5            mov     esp,ebp
007626d2 5d              pop     ebp
007626d3 c3              ret

ds:[133404h] 주소에 어떤 값이 들어 있는지, "Alt + 5(Memory)"를 눌러 확인해보니 0x13c015 값이 나오는 군요.

windbg_disassembly_step_into_1.png

여기까지가, 지난번 글(.NET Disassembly 창에서의 F11(Step-into) 키 동작")의 .NET Disassembly 창을 통한 출력 부분까지 수작업으로 온 것입니다.




이제, 지난번에 확인할 수 없었던 것들을 한번 탐구해볼까요? ^^

원했던 데로, call 명령어에 BP를 걸어 두고, 그곳까지 실행시킵니다. (Console.ReadLine 상태이므로 '엔터 키'를 쳐야 합니다.)

0:008> bp 007626b5

0:008> g
Breakpoint 0 hit
eax=03261ab4 ebx=00000000 ecx=0326bbac edx=00000000 esi=0047ca60 edi=003cedb0
eip=007626b5 esp=003ced78 ebp=003ced84 iopl=0         nv up ei ng nz ac po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000293
007626b5 ff1504341300    call    dword ptr ds:[133404h] ds:002b:00133404=0013c015

'F11 (Step-into)' 키를 누르면 원하는 대로 EIP=0x13c015로 이동하는 것을 확인할 수 있습니다.

0:000> t <== step-into 명령어
eax=03261ab4 ebx=00000000 ecx=0326bbac edx=00000000 esi=0047ca60 edi=003cedb0
eip=0013c015 esp=003ced74 ebp=003ced84 iopl=0         nv up ei ng nz ac po cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000293
0013c015 b003            mov     al,3

이후 해당 코드에 대해서 차례로 역어셈블을 하면서 코드를 확인하면 다음과 같습니다.

0:000> u 0013c015
0013c015 b003            mov     al,3
0013c017 eb04            jmp     0013c01d
0013c019 b006            mov     al,6
0013c01b eb00            jmp     0013c01d
0013c01d 0fb6c0          movzx   eax,al
0013c020 c1e002          shl     eax,2
0013c023 05f0331300      add     eax,1333F0h
0013c028 e9e347a000      jmp     00b40810

0:000> u 0013c01d
0013c01d 0fb6c0          movzx   eax,al
0013c020 c1e002          shl     eax,2
0013c023 05f0331300      add     eax,1333F0h
0013c028 e9e347a000      jmp     00b40810
0013c02d 0000            add     byte ptr [eax],al
0013c02f 00e8            add     al,ch
0013c031 b362            mov     bl,62h
0013c033 f36f            rep outs dx,dword ptr [esi]

0:000> uf 00b40810
00b40810 50              push    eax
00b40811 52              push    edx
00b40812 68f0360770      push    offset clr!PrestubMethodFrame::`vftable' (700736f0)
00b40817 55              push    ebp
00b40818 53              push    ebx
00b40819 56              push    esi
00b4081a 57              push    edi
00b4081b 8d742410        lea     esi,[esp+10h]
00b4081f ff760c          push    dword ptr [esi+0Ch]
00b40822 55              push    ebp
00b40823 89e5            mov     ebp,esp
00b40825 51              push    ecx
00b40826 52              push    edx
00b40827 648b1d780e0000  mov     ebx,dword ptr fs:[0E78h]
00b4082e 8b7b0c          mov     edi,dword ptr [ebx+0Ch]
00b40831 897e04          mov     dword ptr [esi+4],edi
00b40834 89730c          mov     dword ptr [ebx+0Ch],esi
00b40837 6849783df4      push    0F43D7849h
00b4083c 56              push    esi
00b4083d e8ff17556f      call    clr!PreStubWorker (70092041)
00b40842 897b0c          mov     dword ptr [ebx+0Ch],edi
00b40845 8b4e08          mov     ecx,dword ptr [esi+8]
00b40848 894608          mov     dword ptr [esi+8],eax
00b4084b 8bc1            mov     eax,ecx
00b4084d 83c404          add     esp,4
00b40850 5a              pop     edx
00b40851 59              pop     ecx
00b40852 89ec            mov     esp,ebp
00b40854 5d              pop     ebp
00b40855 83c404          add     esp,4
00b40858 5f              pop     edi
00b40859 5e              pop     esi
00b4085a 5b              pop     ebx
00b4085b 5d              pop     ebp
00b4085c 83c408          add     esp,8
00b4085f c3              ret

음... 더 이상 알게 뭡니까? 이 정도해서 clr!PreStubWorker 메서드를 호출한다는 것까지 봤으면 된 거죠? ^^;

그래도, 정말 clr!PreStubWorker 함수가 JIT 역할을 하는지 보기 위해서 그 지점까지 다시 bp를 걸고 F10(Step-over)를 해보겠습니다.

0:000> bp 00b4083d

0:000> g
Breakpoint 1 hit
eax=001333fc ebx=0047ca60 ecx=0326bbac edx=00000000 esi=003ced68 edi=003cefbc
eip=00b4083d esp=003ced40 ebp=003ced50 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
00b4083d e8ff17556f      call    clr!PreStubWorker (70092041)

0:000> p <== step-over 명령어
eax=00767a20 ebx=0047ca60 ecx=7009214a edx=00000002 esi=003ced68 edi=003cefbc
eip=00b40842 esp=003ced44 ebp=003ced50 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
00b40842 897b0c          mov     dword ptr [ebx+0Ch],edi ds:002b:0047ca6c=003ced68

재미있는 것은, "call clr!PreStubWorker" 코드의 반환값이 담긴 eax 레지스터에 "00767a20" 값이 담겨있고, 동시에 위에서 메모리 창을 통해 확인한 0x133404 에 위치한 값이 0x13c015에서 0x00767a20로 바뀌었음을 볼 수 있습니다.

windbg_disassembly_step_into_2.png

그리고, 마지막 ret 문에서 한 단계 더 명령어를 실행하면 EIP가 0x767a20으로 변하는 것을 확인할 수 있습니다.

0:000> t
eax=001333fc ebx=00000000 ecx=0326bbac edx=00000000 esi=0047ca60 edi=003cedb0
eip=00b4085f esp=003ced70 ebp=003ced84 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
00b4085f c3              ret

0:000> t
eax=001333fc ebx=00000000 ecx=0326bbac edx=00000000 esi=0047ca60 edi=003cedb0
eip=00767a20 esp=003ced74 ebp=003ced84 iopl=0         nv up ei pl nz ac po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000212
00767a20 55              push    ebp

0x767a20 지점의 기계어 코드를 한번 확인해 볼까요? 예상하는 것처럼, IL 코드로 존재하던 닷넷 메서드가 JIT 컴파일 된 기계어가 위치하고 있습니다.

0:000> uf 00767a20
00767a20 55              push    ebp
00767a21 8bec            mov     ebp,esp
00767a23 50              push    eax
00767a24 894dfc          mov     dword ptr [ebp-4],ecx
00767a27 833d3c31130000  cmp     dword ptr ds:[13313Ch],0
00767a2e 7405            je      00767a35
00767a30 e8e6e9bb6f      call    clr!JIT_DbgIsJustMyCode (7032641b)
00767a35 90              nop
00767a36 8b0d68372604    mov     ecx,dword ptr ds:[4263768h]
00767a3c ff1538737200    call    dword ptr ds:[727338h]  <=== Console.WriteLine 호출
00767a42 90              nop
00767a43 90              nop
00767a44 8be5            mov     esp,ebp
00767a46 5d              pop     ebp
00767a47 c3              ret

따라서, 이렇게 한번 JIT 컴파일 된 이후에 동일하게 "call dword ptr ds:[133404h]" 코드가 호출되면 더 이상의 PreStubWorker 실행 없이 곧바로 기계어로 변환된 함수를 실행시키게 되는 것입니다.

비록 현실적인 .NET 프로그래밍에 도움이 되진 않겠지만, 그래도 ^^ 가끔 이런 탐구를 하는 것도 나름 재미있기는 합니다.

[연관 글]






[최초 등록일: ]
[최종 수정일: 11/20/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2015-01-05 02시35분
.NET Internals and Native Compiling
; http://www.ntcore.com/files/netint_native.htm

.NET Internals and Code Injection
; http://www.ntcore.com/files/netint_injection.htm
정성태

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13567정성태2/27/20241827오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/20241884오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20241724닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20241963Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
13563정성태2/21/20241959디버깅 기술: 196. windbg - async/await 비동기인 경우 메모리 덤프 분석의 어려움
13562정성태2/21/20241992오류 유형: 896. ASP.NET - .NET Framework 기본 예제에서 System.Web에 대한 System.IO.FileNotFoundException 예외 발생
13561정성태2/20/20242078닷넷: 2218. C# - (예를 들어, Socket) 비동기 I/O에 대한 await 호출 시 CancellationToken을 이용한 취소파일 다운로드1
13560정성태2/19/20242122디버깅 기술: 195. windbg 분석 사례 - Semaphore 잠금으로 인한 Hang 현상 (닷넷)
13559정성태2/19/20242951오류 유형: 895. ASP.NET - System.Security.SecurityException: 'Requested registry access is not allowed.'
13558정성태2/18/20242195닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20241925Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20241987Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20242136닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20241865VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20241952닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20241903닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20242098닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20242214Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20242526개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20242344개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20242112개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20241996Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20241878닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20241895오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20241924Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20241920오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...