Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 5개 있습니다.)
.NET Framework: 634. C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (1) - x86 환경에서의 __cdecl, __stdcall에 대한 Name mangling
; https://www.sysnet.pe.kr/2/0/11132

.NET Framework: 635. C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (2) - x86 환경의 __fastcall
; https://www.sysnet.pe.kr/2/0/11133

.NET Framework: 637. C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (3) - x64 환경의 __fastcall과 Name mangling
; https://www.sysnet.pe.kr/2/0/11139

.NET Framework: 639. C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (4) - CLR JIT 컴파일러의 P/Invoke 호출 규약
; https://www.sysnet.pe.kr/2/0/11141

.NET Framework: 642. C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (부록 1) - CallingConvention.StdCall, CallingConvention.Cdecl에 상관없이 왜 호출이 잘 될까요?
; https://www.sysnet.pe.kr/2/0/11144




C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (4) - CLR JIT 컴파일러의 P/Invoke 호출 규약

지금까지, Win32 DLL 측에서 제공하는 __cdecl, __stdcall, __fastcall 호출에 대한 개요를 알아봤는데요. 그렇다면, 닷넷 측에서는 P/Invoke 호출을 어떤 방식으로 처리할까요? (이게 좀 재미있습니다. ^^)

잠시 x86 닷넷 응용 프로그램으로 테스트를 해볼까요?

다음과 같이 __cdecl, __stdcall 호출 규약을 갖는 C++ 측 export 함수를 준비하고,

// Header 파일
extern "C"
{
    __declspec(dllexport) int __cdecl ExternC_CDECL_Func_Arg5(int value1, int value2, int value3, int value4, int value5);
    __declspec(dllexport) int __stdcall ExternC_STD_Func_Arg5(int value1, int value2, int value3, int value4, int value5);
}

// C++ 구현 파일
__declspec(dllexport) int __cdecl ExternC_CDECL_Func_Arg5(int value1, int value2, int value3, int value4, int value5)
{
    printf("ExternC_CDECL_Func_Arg5: %d, %d, %d, %d, %d\n", value1, value2, value3, value4, value5);
    return 42;
}

__declspec(dllexport) int __stdcall ExternC_STD_Func_Arg5(int value1, int value2, int value3, int value4, int value5)
{
    printf("ExternC_STD_Func_Arg5: %d, %d, %d, %d, %d\n", value1, value2, value3, value4, value5);
    return 42;
}

C#에서 다음과 같이 사용해 봅니다.

[DllImport("Win32Project1.dll", CallingConvention = CallingConvention.Cdecl)]
internal unsafe static extern int ExternC_CDECL_Func_Arg5(int value1, int value2, int value3, int value4, int value5);

[DllImport("Win32Project1.dll")]
internal unsafe static extern int ExternC_STD_Func_Arg5(int value1, int value2, int value3, int value4, int value5);

static unsafe void Main(string[] args)
{
    ExternC_CDECL_Func_Arg5(1, 2, 3, 4, 5);
    ExternC_STD_Func_Arg5(6, 7, 8, 9, 10);
}

그런 다음, Main 함수 마지막 '}'에 BP를 설정하고 F5 (Start Debugging)을 누릅니다. 디버깅 모드로 진입했으면 이제 소스 코드에서 마우스 우 클릭을 해 "Go To Disassembly" 창을 띄우고, 어셈블리 코드를 확인하면 다음과 같이 나옵니다.

        ExternC_CDECL_Func_Arg5(1, 2, 3, 4, 5);
0176046B  push        3  
0176046D  push        4  
0176046F  push        5  
01760471  mov         ecx,1  
01760476  mov         edx,2  
0176047B  call        01760128  
01760480  mov         dword ptr [ebp-40h],eax  
01760483  nop  
        ExternC_STD_Func_Arg5(6, 7, 8, 9, 10);
01760484  push        8  
01760486  push        9  
01760488  push        0Ah  
0176048A  mov         ecx,6  
0176048F  mov         edx,7  
01760494  call        01760188  
01760499  mov         dword ptr [ebp-44h],eax  
0176049C  nop  

가만 보면, call 이전에 실행되는 인자 전달 방식이 __cdecl이나 __stdcall이나 차이가 없습니다. 게다가 ecx, edx에 처음 2개의 인자를 전달하는 걸로 봐서 __fastcall 방식인 듯한데, push로 전달되는 인자의 순서가 left-to-right 순으로 되어 있으니 __fastcall이 아닙니다. 검색해 보면,

x86 calling conventions
; https://en.wikipedia.org/wiki/X86_calling_conventions

32비트 Delphi에서 기본 호출 규약으로 사용되었던 "Borland register" 방식과 유사합니다. 단지, "register" 호출 방식은 처음 3개의 인자를 eax, edx, ecx에 전달하는 것인데, CLR JIT 컴파일된 코드의 경우 2개만 전달하고 있습니다. (이렇게 독자적인 호출 방식 때문에 제가 "C# - x86 실행 환경에서 SECURITY_ATTRIBUTES 구조체를 CreateEvent에 전달할 때 예외 발생" 글에서 이상하다고 했던 것입니다.)

어쨌든 저런 식으로 전달되어도 잘 동작하는 이유는, .NET CLR은 P/Invoke 함수 호출을 한 단계 추상화시켜 호출하기 때문입니다. 즉, 저 위의 "call 01760128", "call 01760188"의 "0x01760128", "0x01760188" 주소는 ExternC_CDECL_Func_Arg5, ExternC_STD_Func_Arg5 함수의 주소가 아니라 CLR의 P/Invoke 층에 있는 래퍼 함수의 주소입니다. 결국, CLR에서 어떻게 전달했든지에 상관없이 래퍼 함수에서만 정상적으로 처리하면 그만인 것입니다.

그럼, x64 프로세스의 경우에는 어떨까요? 어차피 Windows 수준에서 단일하게 처리하므로 이상할 것도 없이 P/Invoke 수준에서도 동일한 방식으로 처리합니다.

ExternC_CDECL_Func_Arg5(1, 2, 3, 4, 5);
00007FF93DAC04A8  mov         dword ptr [rsp+20h],5  
00007FF93DAC04B0  mov         ecx,1  
00007FF93DAC04B5  mov         edx,2  
00007FF93DAC04BA  mov         r8d,3  
00007FF93DAC04C0  mov         r9d,4  
00007FF93DAC04C6  call        00007FF93DAC0098  

ExternC_STD_Func_Arg5(6, 7, 8, 9, 10);
00007FF93DAC04CF  mov         dword ptr [rsp+20h],0Ah  
00007FF93DAC04D7  mov         ecx,6  
00007FF93DAC04DC  mov         edx,7  
00007FF93DAC04E1  mov         r8d,8  
00007FF93DAC04E7  mov         r9d,9  
00007FF93DAC04ED  call        00007FF93DAC00A8  

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




정리해 보면, CLR JIT 컴파일러는 P/Invoke 호출을 하나의 정형화된 방법으로 처리를 하고, 이후의 호출 규약에 따른 세부적인 처리는 그에 대응하는 래퍼 함수가 처리하게 됩니다.

아쉽지만, Visual Studio를 이용한 분석은 여기까지가 끝입니다. F11 (Step Into) 기능으로 저 call 주소를 들어가려고 해도 곧바로 C/C++ 측에서 제공한 코드로 점프하기 때문에 중간의 CLR Wrapper 함수를 확인할 수 없습니다. 이를 원한다면 windbg.exe와 같은 별도의 디버거 도구를 이용해야 합니다. 일단, 닷넷 개발자라면 이쯤에서 만족하고 더 이상 글을 안 읽으셔도 됩니다. ^^

혹시나... 그래도 ^^ 그냥 덮기 아쉬운 분은, 다음의 부록 글을 읽어보시면 됩니다.

C# 개발자를 위한 Win32 DLL export 함수의 호출 규약 (부록 1) - CallingConvention.StdCall, CallingConvention.Cdecl에 상관없이 왜 호출이 잘 될까요?
; https://www.sysnet.pe.kr/2/0/11144




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







[최초 등록일: ]
[최종 수정일: 8/18/2023]

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

비밀번호

댓글 작성자
 



2017-02-02 02시36분
[짜두] 나이스한 정리입니다아~~
[guest]

... 91  92  93  94  95  96  [97]  98  99  100  101  102  103  104  105  ...
NoWriterDateCnt.TitleFile(s)
11509정성태4/28/201819968.NET Framework: 741. windbg로 확인하는 객체의 GC 여부
11508정성태4/23/201821548개발 환경 구성: 373. MSBuild를 이용해 프로젝트 배포 후 결과물을 zip 파일로 압축하는 방법파일 다운로드1
11507정성태4/20/201821426개발 환경 구성: 372. MSBuild - 빌드 전/후, 배포 전/후 실행하고 싶은 Task 정의
11506정성태4/20/201825720.NET Framework: 740. C#에서 enum을 boxing 없이 int로 변환하기 - 두 번째 이야기 [7]파일 다운로드1
11505정성태4/19/201818536개발 환경 구성: 371. Azure Web App 확장 예제 - Simple WebSite Extension
11504정성태4/19/201819976오류 유형: 465. Azure Web App 확장 - Extplorer File manager 적용 시 오류
11503정성태4/19/201819835오류 유형: 464. PowerShell - Start-Service 명령 오류 (Service 'xxx' cannot be started)
11502정성태4/17/201821696개발 환경 구성: 370. Azure VM/App Services(Web Apps)에 Let's Encrypt 무료 인증서 적용 방법 [3]
11501정성태4/17/201818597개발 환경 구성: 369. New-AzureRmADServicePrincipal로 생성한 계정의 clientSecret, key 값을 구하는 방법파일 다운로드1
11500정성태4/17/201819537개발 환경 구성: 368. PowerShell로 접근하는 Azure의 Access control 보안과 Azure Active Directory의 계정 관리 서비스
11499정성태4/17/201818166개발 환경 구성: 367. Azure - New-AzureRmADServicePrincipal / New-AzureRmRoleAssignment 명령어
11498정성태4/17/201818223개발 환경 구성: 366. Azure Active Directory(Microsoft Enfra ID)의 사용자 유형 구분 - Guest/Member
11497정성태4/17/201816273개발 환경 구성: 365. Azure 리소스의 액세스 제어(Access control) 별로 사용자에게 권한을 할당하는 방법 [2]
11496정성태4/17/201816702개발 환경 구성: 364. Azure Portal에서 구독(Subscriptions) 메뉴가 보이지 않는 경우
11495정성태4/16/201819008개발 환경 구성: 363. Azure의 Access control 보안과 Azure Active Directory의 계정 관리 서비스
11494정성태4/16/201815500개발 환경 구성: 362. Azure Web Apps(App Services)에 사용자 DNS를 지정하는 방법
11493정성태4/16/201817301개발 환경 구성: 361. Azure Web App(App Service)의 HTTP/2 프로토콜 지원
11492정성태4/13/201815292개발 환경 구성: 360. Azure Active Directory의 사용자 도메인 지정 방법
11491정성태4/13/201818425개발 환경 구성: 359. Azure 가상 머신에 Web Application을 배포하는 방법
11490정성태4/12/201817469.NET Framework: 739. .NET Framework 4.7.1의 새 기능 - Configuration builders [1]파일 다운로드1
11489정성태4/12/201815099오류 유형: 463. 윈도우 백업 오류 - a Volume Shadow Copy Service operation failed.
11488정성태4/12/201818210오류 유형: 462. Unhandled Exception in Managed Code Snap-in - FX:{811FD892-5EB4-4E73-A147-F1E079E36C4E}
11487정성태4/12/201817306디버깅 기술: 115. windbg - 닷넷 메모리 덤프에서 정적(static) 필드 값을 조사하는 방법
11486정성태4/11/201816429오류 유형: 461. Error MSB4064 The "ComputeOutputOnly" parameter is not supported by the "VsTsc" task
11485정성태4/11/201823633.NET Framework: 738. C# - Console 프로그램이 Ctrl+C 종료 시점을 감지하는 방법파일 다운로드1
11484정성태4/11/201824738.NET Framework: 737. C# - async를 Task 타입이 아닌 사용자 정의 타입에 적용하는 방법파일 다운로드1
... 91  92  93  94  95  96  [97]  98  99  100  101  102  103  104  105  ...