Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 4개 있습니다.)
(시리즈 글이 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 함수의 호출 규약 (3) - x64 환경의 __fastcall과 Name mangling

x64의 경우, 윈도우 자체가 ABI(Application Binary Interface)의 요구 사항 수준에서 calling convention을 __fastcall 단 한 개로 정리해 버렸습니다.

그런데, __fastcall이라고는 하지만 x86의 __fastcall과는 약간 다릅니다. 가령, x86의 경우 처음 2개의 인자만 ecx, edx로 넘기고 나머지는 스택을 통해 전달합니다. 반면 x64에서는 처음 4개의 인자를 rcx, rdx, r8, r9로 넘기고 이후의 인자는 스택으로 전달합니다. (하지만, 처음 4개의 인자를 위한 스택도 할당합니다.) 심지어 이름조차도 Wikipedia에서는,

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

__fastcall이 아닌 "Microsoft x64 calling convention"이라고 지칭합니다. 이런 상황에서 마이크로소프트는 공식 문서에,

x64 calling convention
; https://learn.microsoft.com/en-us/cpp/build/x64-software-conventions

Given the expanded register set, x64 uses the __fastcall calling convention and a RISC-based exception-handling model. The __fastcall convention uses registers for the first four arguments and the stack frame to pass additional arguments.


__fastcall이라고 명시합니다. 이렇게 혼란스러운 면이 있지만, 여기서는 마이크로소프트의 문서에 따라 __fastcall 호출 규약이라고 하겠습니다.




이름이야 뭐든지 간에, 덕분에 C++에서 해당 함수를 __cdecl이든 __stdcall이든 예약어를 지정해도 Visual C++ 컴파일러는 이를 무시하고 무조건 __fastcall 호출 규약으로 만들어 버립니다. 이로 인해 Name mangling도 간편해지는데, C++ 이름 형식이어야 하는 export 함수들을 제외하고는 전부 - .def에 명시했든, extern "C"로 하든 - 함수 이름 자체를 그대로 노출시킵니다. 가령, export 함수들을 다음과 같이 선언했을 때,

__declspec(dllexport) int __cdecl CDECL_Func(int value);
__declspec(dllexport) int __cdecl CDECL_Func_By_DEF(int value); // .def 파일에 명시

extern "C"
{
    __declspec(dllexport) __cdecl int ExternC_CDECL_Func(int value);
    __declspec(dllexport) __cdecl int ExternC_CDECL_Func_Arg2(int value, int *pValue);
    __declspec(dllexport) __cdecl int ExternC_CDECL_Func_Arg5(int value1, int value2, int value3, int value4, int value5);
    __declspec(dllexport) __cdecl int ExternC_CDECL_Func_By_DEF(int value);
}

__declspec(dllexport) int __stdcall STD_Func(int value);
__declspec(dllexport) int __stdcall STD_Func_By_DEF(int value);  // .def 파일에 명시

extern "C"
{
    __declspec(dllexport) int __stdcall ExternC_STD_Func0();
    __declspec(dllexport) int __stdcall ExternC_STD_Func(int value);
    __declspec(dllexport) int __stdcall ExternC_STD_Func2(int value);
    __declspec(dllexport) int __stdcall ExternC_STD_Func_Arg2(int value, int *pValue);
    __declspec(dllexport) int __stdcall ExternC_STD_Func_By_DEF(int value);
}

빌드하면 DLL Export 함수 이름들이 이렇게 나옵니다.

?CDECL_Func@@YAHH@Z
CDECL_Func_By_DEF
?STD_Func@@YAHH@Z
STD_Func_By_DEF
ExternC_CDECL_Func
ExternC_CDECL_Func_Arg2
ExternC_CDECL_Func_Arg5
ExternC_CDECL_Func_By_DEF
ExternC_STD_Func
ExternC_STD_Func0
ExternC_STD_Func2
ExternC_STD_Func_Arg2
ExternC_STD_Func_By_DEF

당연히, 닷넷 측에서도 DllImport를 지정하는 방법이 간편해졌습니다. 운영체제 차원의 CallingConvention이 통합되었으므로 닷넷 역시 DllImport에 개발자가 어떻게 명시하든 그것을 무시해버리고 x64의 __fastcall 호출 규약을 따른다고 가정합니다.

따라서, x86에서는 __cdecl 호출 규약을 다음과 같이 정의해야 했지만,

[DllImport("Win32Project1.dll", CallingConvention = CallingConvention.Cdecl)]
internal static extern int ExternC_CDECL_Func(int value);

x64 빌드 용이라면 다음과 같이 해도 무방합니다.

[DllImport("Win32Project1.dll")]
internal static extern int ExternC_CDECL_Func(int value);

심지어 __stdcall로 지정해도 됩니다. (어차피 무시하므로!)

[DllImport("Win32Project1.dll", CallingConvention = CallingConvention.StdCall)]
internal static extern int ExternC_CDECL_Func(int value);

당연히 Visual Studio 디버거에서도 (무시할 호출 규약을 지정했다고 해서) PInvokeStackImbalance MDA 예외를 발생시키지 않습니다. 적어도 x64 세계에서는, 호출 규약의 복잡함이 없어졌기 때문에 개발자 입장에서는 반가운 변화입니다. ^^

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




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

[연관 글]






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

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

비밀번호

댓글 작성자
 



2017-08-22 04시09분
정성태

... 76  77  78  79  80  81  82  83  84  85  86  87  88  89  [90]  ...
NoWriterDateCnt.TitleFile(s)
11388정성태12/6/201714523개발 환경 구성: 338. WSL 또는 Ubuntu에 닷넷 코어 설치 [3]
11387정성태12/6/201715065오류 유형: 439. 이벤트 로그 - Data Sharing Service 서비스의 %%3239247874 오류 메시지
11386정성태12/5/201710991오류 유형: 438. Hyper-V - '...' failed to add device 'Virtual CD/DVD Disk'
11385정성태12/5/201722584VC++: 121. DXGI를 이용한 윈도우 화면 캡처 소스 코드(Visual C++) [16]파일 다운로드1
11384정성태12/5/201712937오류 유형: 437. Visual C++ - Cannot open include file: 'SDKDDKVer.h'
11383정성태12/4/201715933디버깅 기술: 110. 비동기 코드 실행 중 예외로 인한 ASP.NET 프로세스 비정상 종료 현상 [1]
11382정성태12/4/201714722오류 유형: 436. System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired 예외 발생 시 "[Pre-Login] initialization=48; handshake=1944;" 값의 의미
11381정성태11/30/201711231.NET Framework: 702. 한글이 포함된 바이트 배열을 나눈 경우 한글이 깨지지 않도록 다시 조합하는 방법(두 번째 이야기)파일 다운로드1
11380정성태11/30/201711355디버깅 기술: 109. windbg - (x64에서의 인자 값 추적을 이용한) Thread.Abort 시 대상이 되는 스레드를 식별하는 방법
11379정성태11/30/201711721오류 유형: 435. System.Web.HttpException - Session state has created a session id, but cannot save it because the response was already flushed by the application.
11378정성태11/29/201713559.NET Framework: 701. 한글이 포함된 바이트 배열을 나눈 경우 한글이 깨지지 않도록 다시 조합하는 방법 [1]파일 다운로드1
11377정성태11/29/201712735.NET Framework: 700. CommonOpenFileDialog 사용 시 사용자가 선택한 파일 목록을 구하는 방법 [3]파일 다운로드1
11376정성태11/28/201716094VS.NET IDE: 123. Visual Studio 편집기의 \r\n (crlf) 개행을 \n으로 폴더 단위로 설정하는 방법
11375정성태11/28/201712537오류 유형: 434. Visual Studio로 ASP.NET 디버깅 중 System.Web.HttpException - Could not load type 오류
11374정성태11/27/201717137사물인터넷: 14. 라즈베리 파이 - (윈도우의 NT 서비스처럼) 부팅 시 시작하는 프로그램 설정 [1]
11373정성태11/27/201716189오류 유형: 433. Raspberry Pi/Windows 다중 플랫폼 지원 컴파일 관련 오류 기록
11372정성태11/25/201719440사물인터넷: 13. 윈도우즈 사용자를 위한 라즈베리 파이 제로 W 모델을 설정하는 방법 [4]
11371정성태11/25/201713365오류 유형: 432. Hyper-V 가상 스위치 생성 시 Failed to connect Ethernet switch port 0x80070002 오류 발생
11370정성태11/25/201712963오류 유형: 431. Hyper-V의 Virtual Switch 생성 시 "External network" 목록에 특정 네트워크 어댑터 항목이 없는 경우
11369정성태11/25/201715322사물인터넷: 12. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 키보드 및 마우스로 쓰는 방법 (절대 좌표, 상대 좌표, 휠) [1]
11368정성태11/25/201720345.NET Framework: 699. UDP 브로드캐스트 주소 255.255.255.255와 192.168.0.255의 차이점과 이를 고려한 C# UDP 서버/클라이언트 예제 [2]파일 다운로드1
11367정성태11/25/201720485개발 환경 구성: 337. 윈도우 운영체제의 route 명령어 사용법
11366정성태11/25/201712283오류 유형: 430. 이벤트 로그 - Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
11365정성태11/25/201714556오류 유형: 429. 이벤트 로그 - User Policy could not be updated successfully
11364정성태11/24/201715668사물인터넷: 11. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스로 쓰는 방법 (절대 좌표) [2]
11363정성태11/23/201715370사물인터넷: 10. Raspberry Pi Zero(OTG)를 다른 컴퓨터에 연결해 가상 마우스 + 키보드로 쓰는 방법 (두 번째 이야기)
... 76  77  78  79  80  81  82  83  84  85  86  87  88  89  [90]  ...