Microsoft MVP성태의 닷넷 이야기
.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64 [링크 복사], [링크+제목 복사]
조회: 1080
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

상황별 GetFunctionPointer 반환값 정리 - x64

지난 글에서는,

상황별 GetFunctionPointer 반환값 정리 - x86
; https://www.sysnet.pe.kr/2/0/1027

x86을 대상으로만 했었는데, 이번에는 .NET 4.8 / x64 / Debug 빌드로 실행한 결과를 정리해 보겠습니다.


EXE 어셈블리의 Main 메서드

class Program
{
    static void Main(string[] args)
    {
        ShowMainFunc();
    }

    static void ShowMainFunc()
    {
        MethodBase func = typeof(Program).GetMethod("Main", BindingFlags.Static | BindingFlags.NonPublic);
        IntPtr pMain = func.MethodHandle.GetFunctionPointer();
        OutputFunctionAddress("Main", pMain);
    }

    private static void OutputFunctionAddress(string title, IntPtr pAddr)
    {
        Console.WriteLine($"{title} == {pAddr.ToInt64():x}");
    }
}

x86과 결과와 다르지 않습니다. 특이한 점이 있다면 "Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기" 글에서의 PreStub 과정 없이 곧바로 Fixup Precode에서 Native Code를 호출하는 jmp 문으로 패치된다는 점입니다. (Main 함수야말로 단 한번 실행되는 경우가 대부분일 것이므로 굳이 공을 들여 최적화를 안 해도 될 텐데 말이죠. ^^)

또한 MethodDesc 위치의 +8 바이트 위치에 저장한 기계어 코드의 주소도 GetFunctionPointer의 값과 일치합니다.


어셈블리에 정의된 메서드의 JIT 이전

class Program
{
    static void Main(string[] args)
    {
        ShowTestFunc("Test1 - Before JITting", "Test1");
        Console.ReadLine();

        Program pg = new Program();
        pg.Test1();
    }

    private void Test1()
    {
        Console.WriteLine("Test1 called!");
    }

    static void ShowTestFunc(string text, string methodName)
    {
        MethodBase func = typeof(Program).GetMethod(methodName, BindingFlags.Instance | BindingFlags.NonPublic);
        IntPtr pFunc = func.MethodHandle.GetFunctionPointer();
        OutputFunctionAddress(text, pFunc);
    }

    private static void OutputFunctionAddress(string title, IntPtr pAddr)
    {
        Console.WriteLine($"{title} == {pAddr.ToInt64():x}");
    }
}

/* 출력 결과
Test1 - Before JITting == 7ffe48310488
*/

이에 대해서도 "Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기" 글에서 살펴봤습니다. GetFunctionPointer가 반환한 주소는 "Fixup Precode"를 가리키고 실제 호출하려고 할 때의 call 코드의 변위도 정확히 GetFunctionPointer의 반환 주소를 가리킵니다. (따라서 x86의 call 주솟값과는 다르다는 차이점이 있습니다.)

00007ffe`48310912 e871fbffff      call    00007ffe`48310488 (Program.Test1(), mdToken: 0000000006000002)


어셈블리에 정의된 메서드의 JIT 이후

static void Main(string[] args)
{
    ShowTestFunc("Test1 - Before JITting", "Test1");

    Program pg = new Program();
    pg.Test1();

    ShowTestFunc("Test1 - After JITting", "Test1");
}

/* 출력 결과
Test1 - Before JITting == 7ffe48300488
Test1 called!
Test1 - After JITting == 7ffe48300c10
*/

이번에도 "Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기" 글의 내용과 일치합니다.

0:000> !name2ee ConsoleApp1.exe!Program.Test1 
Module:      00007ffe481f4148
Assembly:    ConsoleApp1.exe
Token:       0000000006000002
MethodDesc:  00007ffe481f5a10
Name:        Program.Test1()
JITTED Code Address: 00007ffe48300c10

0:000> dq 00007ffe481f5a10 L2
00007ffe`481f5a10  00080006`21020002 00007ffe`48300c10

정리해 보면, Jit 전에는 Fixup Precode의 위치를 GetFunctionPointer 메서드가 반환하지만, 일단 JIT가 되면 GetFunctionPointer는 해당 메서드의 Body가 컴파일된 메서드의 주솟값을 반환합니다.


NGen 된 BCL(Base Class Library) 메서드

public static void ShowCreateCommandAddress()
{
    MethodBase func = typeof(SqlConnection).GetMethod("CreateCommand", BindingFlags.Instance | BindingFlags.Public);

    IntPtr pOld = func.MethodHandle.GetFunctionPointer();
    OutputFunctionAddress("CreateCommand", pOld);
}

/* 출력 결과
CreateCommand == 7ffe48320510
*/

GetFunctionPointer가 반환한 값(7ffe48320510)은 특이하게 Fixup Precode의 위치입니다. (게다가 method desc을 구하는 인덱스가 모두 0, 0입니다.)

0:000> !u 7ffe48320510
Unmanaged code
00007ffe`48320510 e80b40545f      call    clr!PrecodeFixupThunk (00007ffe`a7864520)
00007ffe`48320515 5e              pop     rsi
00007ffe`48320516 0000            add     byte ptr [rax],al
00007ffe`48320518 081d9d72fe7f    or      byte ptr [00007ffe`c83077bb],bl

0:000> !ip2md  7ffe48320510 // 왜냐하면 fixup precode의 위치이므로.
Failed to request MethodData, not in JIT code range

하지만, 해당 메서드의 MethodDesc 값에는 정확히 기계어로 번역된 주솟값을 가지고 있습니다.

0:000> !name2ee System.Data.dll!System.Data.SqlClient.SqlConnection.CreateCommand
Module:      00007ffe72961000
Assembly:    System.Data.dll
Token:       0000000006001a69
MethodDesc:  00007ffe729d1d08
Name:        System.Data.SqlClient.SqlConnection.CreateCommand()
JITTED Code Address: 00007ffe72ea4410

0:000> dq 00007ffe729d1d08 L2
00007ffe`729d1d08  00006453`3b7c9a69 00000000`004d2700

0:000> ? 00007ffe`729d1d10 + 004d2700
Evaluate expression: 140730826376208 = 00007ffe`72ea4410

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




이 외에 재미있는 거 하나 더 언급해 보면 Visual Studio에서 F5 디버깅을 시작했을 때의 JIT 컴파일이 다소 특별하다는 점입니다. 실제로 그 상태에서 실행해 GetFunctionPointer로 출력된 주소의 값을 JIT 컴파일 전/후에 따라 각각 살펴보면,

// GetFunctionPointer의 반환 값 == 00007FFE48330490

[JIT 전]
00007FFE48330490 E8 8B 40 53 5F       call        00007FFEA7864520  
00007FFE48330495 5E                   pop         rsi  

[JIT 후]
00007FFE48330490 E9 CB 06 00 00       jmp         00007FFE48330B60  
00007FFE48330495 5F                   pop         rdi  

Tiered Compilation 동작을 무시하고 Fixup Precode의 call 코드가 곧바로 Native Code로의 jump 문으로 패치되는 것을 볼 수 있습니다. 게다가 Visual Studio의 디버깅 상태가 아니라면 GetFunctionPointer는 위에서처럼 Fixup Precode의 위치를 가리키지 않고 IL 코드가 번역된 Native Code의 주소를 가리켰다는 점이 다릅니다.




한 마디로, 상황 별로 GetFunctionPointer가 반환하는 값이 달라 이에 대해 어떤 고정적인 동작을 가정하고 코딩해서는 안 됩니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 11/6/2020 ]

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

비밀번호

댓글 쓴 사람
 




... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
12218정성태5/31/20201252.NET Framework: 905. C# - DirectX 게임 클라이언트 실행 중 키보드 입력을 감지하는 방법 [1]
12217정성태5/24/20201153오류 유형: 615. Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 0, current count = 1.
12216정성태2/20/20211599.NET Framework: 904. USB/IP PROJECT를 이용해 C#으로 USB Keyboard 가상 장치 만들기 [13]파일 다운로드1
12215정성태5/12/20203269개발 환경 구성: 490. C# - (Wireshark의) USBPcap을 이용한 USB 패킷 모니터링 [1]파일 다운로드1
12214정성태5/5/20201247개발 환경 구성: 489. 정식 인증서가 있는 경우 Device Driver 서명하는 방법 (2) - UEFI/SecureBoot
12213정성태1/28/20211852개발 환경 구성: 488. (코드로 가상 USB 장치를 만들 수 있는) USB/IP PROJECT 소개
12212정성태5/1/20201095개발 환경 구성: 487. UEFI / Secure Boot 상태인지 확인하는 방법
12211정성태4/27/20201270개발 환경 구성: 486. WSL에서 Makefile로 공개된 리눅스 환경의 C/C++ 소스 코드 빌드
12210정성태4/20/20201669.NET Framework: 903. .NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션 [1]파일 다운로드1
12209정성태4/13/20201135오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/20201404Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/20201177스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/20201298오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/20201118스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/20201049스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/20201472오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/20201855개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/20201404오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token".
12200정성태11/5/20201789VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/20201086오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/20201317오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/20201264VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기
12196정성태3/17/20201114오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/17/20201430.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/20201729오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/20201240개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...