Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 4개 있습니다.)
(시리즈 글이 11개 있습니다.)
.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

.NET Framework: 763. .NET Core 2.1 - Tiered Compilation 도입
; https://www.sysnet.pe.kr/2/0/11539

디버깅 기술: 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 프로그래밍에 도움이 되진 않겠지만, 그래도 ^^ 가끔 이런 탐구를 하는 것도 나름 재미있기는 합니다.

[연관 글]






[최초 등록일: ]
[최종 수정일: 4/8/2025]

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
정성태

... 46  47  [48]  49  50  51  52  53  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12736정성태7/28/202115252오류 유형: 743. Active Azure Directory에서 "API permissions"의 권한 설정이 "Not granted for ..."로 나오는 문제
12735정성태7/27/202115156.NET Framework: 1081. C# - Azure AD 인증을 지원하는 데스크톱 애플리케이션 예제(Windows Forms) [2]파일 다운로드1
12734정성태7/26/202131964스크립트: 20. 특정 단어로 시작하거나/끝나는 문자열을 포함/제외하는 정규 표현식 - Look-around
12733정성태7/23/202119844.NET Framework: 1081. Self-Contained/SingleFile 유형의 .NET Core/5+ 실행 파일을 임베딩한다면? [1]파일 다운로드2
12732정성태7/23/202113297오류 유형: 742. SharePoint - The super user account utilized by the cache is not configured.
12731정성태7/23/202115317개발 환경 구성: 584. Add Internal URLs 화면에서 "Save" 버튼이 비활성화 된 경우
12730정성태7/23/202116764개발 환경 구성: 583. Visual Studio Code - Go 코드에서 입력을 받는 경우
12729정성태7/22/202115252.NET Framework: 1080. xUnit 단위 테스트에 메서드/클래스 수준의 문맥 제공 - Fixture
12728정성태7/22/202115274.NET Framework: 1079. MSTestv2 단위 테스트에 메서드/클래스/어셈블리 수준의 문맥 제공
12727정성태7/21/202116459.NET Framework: 1078. C# 단위 테스트 - MSTestv2/NUnit의 Assert.Inconclusive 사용법(?) [1]
12726정성태7/21/202116232VS.NET IDE: 169. 비주얼 스튜디오 - 단위 테스트 선택 시 MSTestv2 외의 xUnit, NUnit 사용법 [1]
12725정성태7/21/202114693오류 유형: 741. Failed to find the "go" binary in either GOROOT() or PATH
12724정성태7/21/202117588개발 환경 구성: 582. 윈도우 환경에서 Visual Studio Code + Go (Zip) 개발 환경 [1]
12723정성태7/21/202114512오류 유형: 740. SharePoint - Alternate access mappings have not been configured 경고
12722정성태7/20/202114258오류 유형: 739. MSVCR110.dll이 없어 exe 실행이 안 되는 경우
12721정성태7/20/202115411오류 유형: 738. The trust relationship between this workstation and the primary domain failed. - 세 번째 이야기
12720정성태7/19/202114677Linux: 43. .NET Core/5+ 응용 프로그램의 Ubuntu (Debian) 패키지 준비
12719정성태7/19/202113870오류 유형: 737. SharePoint 설치 시 "0x800710D8 The object identifier does not represent a valid object." 오류 발생
12718정성태7/19/202113899개발 환경 구성: 581. Windows에서 WSL로 파일 복사 시 root 소유권으로 적용되는 문제파일 다운로드1
12717정성태7/18/202114090Windows: 195. robocopy에서 파일의 ADS(Alternate Data Stream) 정보 복사를 제외하는 방법
12716정성태7/17/202115229개발 환경 구성: 580. msbuild의 Exec Task에 robocopy를 사용하는 방법파일 다운로드1
12715정성태7/17/202122430오류 유형: 736. Windows - MySQL zip 파일 버전의 "mysqld --skip-grant-tables" 실행 시 비정상 종료 [1]
12714정성태7/16/202115795오류 유형: 735. VCRUNTIME140.dll, MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll이 없어 exe 실행이 안 되는 경우
12713정성태7/16/202117181.NET Framework: 1077. C# - 동기 방식이면서 비동기 규약을 따르게 만드는 Task.FromResult파일 다운로드1
12712정성태7/15/202116106개발 환경 구성: 579. Azure - 리눅스 호스팅의 Site Extension 제작 방법
12711정성태7/15/202116123개발 환경 구성: 578. Azure - Java Web App Service를 위한 Site Extension 제작 방법
... 46  47  [48]  49  50  51  52  53  54  55  56  57  58  59  60  ...