Microsoft MVP성태의 닷넷 이야기
VC++: 138. x64 빌드에서 extern "C"가 아닌 경우 ___cdecl name mangling 적용 [링크 복사], [링크+제목 복사],
조회: 11026
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)

x64 빌드에서 extern "C"가 아닌 경우 __cdecl name mangling 적용

처음 알았군요. ^^; 간단하게 DLL 프로젝트를 만들어, 다음의 헤더 파일과 CPP로,

// 헤더 파일

           __declspec(dllexport) int __stdcall fnDll1(void);
extern "C" __declspec(dllexport) int __stdcall fnDll2(void);

#include "pch.h"
#include "Dll1.h"

__declspec(dllexport) int __stdcall fnDll1(void)
{
    return 0;
}

__declspec(dllexport) int __stdcall fnDll2(void)
{
    return 0;
}

빌드한 결과물에 대해 export 결과는 다음과 같습니다.

[x86]
?fnDll1@@YGHXZ
_fnDll2@0

[x64]
?fnDll1@@YAHXZ
fnDll2

extern "C"가 붙지 않은 fnDll1에 대해 각각 undname으로 풀어 보면,

// Visual C++ name mangling
// ; https://en.wikiversity.org/w/index.php?title=Visual_C%2B%2B_name_mangling&oldid=2371121

[x86]
?fnDll1@@YGHXZ ==> int __stdcall fnDll1(void)

[x64]
?fnDll1@@YAHXZ ==> "int __cdecl fnDll1(void)"

x64의 경우, __stdcall을 명시한 것에 상관없이 __cdecl로 나옵니다. (업데이트 2020-11-20) x64의 경우, extern "C"가 없는 경우 name mangling이 무조건 __cdecl 유형으로 나옵니다. (버그인지, 원래 이런 것인지 혹시 아시는 분은 덧글 부탁드립니다. ^^)

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/20/2024]

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

비밀번호

댓글 작성자
 



2020-11-20 08시31분
[수] 안녕하세요, 언제나 좋은 글 써주셔서 많이 도움 받고 있습니다.

제가 cpp쪽은 문외한이라 잘 이해했는지는 모르겠는데,
https://learn.microsoft.com/ko-kr/cpp/cpp/stdcall?view=msvc-160
이 글을 보니까
Functions declared using the __stdcall modifier return values the same way as functions declared using __cdecl.
On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.
이렇게 쓰여있는데 혹시 이것과 관련된 내용일까요?
__cdecl 항목에도 동일한 내용이 기록되어 있습니다.
[guest]
2020-11-20 09시39분
의견 주셔서 감사합니다. ^^ 제가 또 그 사실을 깜빡하고 있었군요. 예전에도 쓴 글이었는데,

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

x64에서는 원래 (__fastcall 호출 규약만 있어서) 모든 호출 규약을 무시하는데, ... 제가 순간적으로 __cdecl이 적용되는 거에 혼란이 왔습니다. ^^;

그렇긴 한데, 어쨌든 그 문서에서도 x64의 경우 extern "C"가 없을 때 __cdecl이 적용된다는 것에 대한 내용은 아닙니다. 말씀하신데로 __cdecl 문서에서도 x64 빌드에서 그 옵션이 쓰여질 수는 있지만 무시한다는 내용입니다. 따라서 문서상으로 보면 extern "C"의 유무에 상관없이 __fastcall로 나와야 하는데.... 이상하게 __cdecl로 나온 것입니다. 이렇게 알고 나서 보니, 위의 링크에서 예시한 함수들 중에 아래의 2개가,

__declspec(dllexport) int __cdecl CDECL_Func(int value);
==> ?CDECL_Func@@YAHH@Z
==> int __cdecl CDECL_Func(int)

__declspec(dllexport) int __stdcall STD_Func(int value);
==> ?STD_Func@@YAHH@Z
==> int __cdecl STD_Func(int)

라고 풀이되는데, 그때도 역시 extern "C"가 없는 경우 __cdecl로 통일되어 나왔습니다. 그래도 관련 문서 중에 보니까,

https://learn.microsoft.com/en-us/cpp/build/reference/gd-gr-gv-gz-calling-convention

위의 내용에 "__cdecl Specifics"를 보면 ARM과 x64 환경에서는 "__fastcall Specifis"와 동일하게 인자 전달을 하는 것으로 설명하고 있습니다. 아마도 그렇다면 extern "C"가 없는 경우 비록 이름 자체에는 __cdecl을 포함한 name mangling이 되긴 했지만 내부 호출 규약은 __fastcall로 통일된 것에는 변함이 없는 듯합니다.
정성태
2020-11-20 10시16분
테스트 해보니까, 호출 규약 자체가 변한 것은 아니고 x64에서 extern "C"가 붙지 않은 경우 그냥 name mangling만 __cdecl로 하고 있습니다. 덕분에 혼란스러운 것을 정리할 수 있었습니다. ^^
정성태
2020-11-20 03시50분
[수] 와 빠른 피드백 멋지네요!
뭔가 약간 팬심 비슷한게 뭉게뭉게 솟아난 느낌입니다.
덧붙여주신 내용 덕에 한개 더 배워 갑니다. 감사합니다!
[guest]

... 61  62  63  64  65  66  67  68  69  70  [71]  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
11861정성태4/6/201912162디버깅 기술: 126. windbg - .NET x86 CLR2/CLR4 EXE의 EntryPoint
11860정성태4/5/201915439오류 유형: 527. Visual C++ 컴파일 오류 - error C2220: warning treated as error - no 'object' file generated
11859정성태4/4/201912805디버깅 기술: 125. WinDbg로 EXE의 EntryPoint에서 BP 거는 방법
11858정성태3/27/201913256VC++: 129. EXE를 LoadLibrary로 로딩해 PE 헤더에 있는 EntryPoint를 직접 호출하는 방법파일 다운로드1
11857정성태3/26/201912156VC++: 128. strncpy 사용 시 주의 사항(Linux / Windows)
11856정성태3/25/201912141VS.NET IDE: 134. 마이크로소프트의 CoreCLR 프로파일러 리눅스 예제를 Visual Studio F5 원격 디버깅하는 방법 [1]파일 다운로드1
11855정성태3/25/201914176개발 환경 구성: 436. 페이스북 HTTPS 인증을 localhost에서 테스트하는 방법
11854정성태3/25/201910121VS.NET IDE: 133. IIS Express로 호스팅하는 사이트를 https로 접근하는 방법
11853정성태3/24/201912258개발 환경 구성: 435. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면? - 두 번째 이야기 [1]
11852정성태3/20/201912514개발 환경 구성: 434. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면?파일 다운로드1
11851정성태3/19/201915381Linux: 8. C# - 리눅스 환경에서 DllImport 대신 라이브러리 동적 로드 처리 [2]
11850정성태3/18/201913959.NET Framework: 813. C# async 메서드에서 out/ref/in 유형의 인자를 사용하지 못하는 이유
11849정성태3/18/201913735.NET Framework: 812. pscp.exe 기능을 C#으로 제어하는 방법파일 다운로드1
11848정성태3/17/201911131스크립트: 14. 윈도우 CMD - 파일이 변경된 경우 파일명을 변경해 복사하고 싶다면?
11847정성태3/17/201915069Linux: 7. 리눅스 C/C++ - 공유 라이브러리 동적 로딩 후 export 함수 사용 방법파일 다운로드1
11846정성태3/15/201913452Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제
11845정성태3/15/201914173Linux: 5. Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency) [3]
11844정성태3/14/201914990개발 환경 구성: 434. Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정 [1]파일 다운로드1
11843정성태3/14/201910778기타: 75. MSDN 웹 사이트를 기본으로 영문 페이지로 열고 싶다면?
11842정성태3/13/201910176개발 환경 구성: 433. 마이크로소프트의 CoreCLR 프로파일러 예제를 Visual Studio CMake로 빌드하는 방법 [1]파일 다운로드1
11841정성태3/13/201910157VS.NET IDE: 132. Visual Studio 2019 - CMake의 컴파일러를 기본 g++에서 clang++로 변경
11840정성태3/13/201911240오류 유형: 526. 윈도우 10 Ubuntu App 환경에서는 USB 외장 하드 접근 불가
11839정성태3/12/201913962디버깅 기술: 124. .NET Core 웹 앱을 호스팅하는 Azure App Services의 프로세스 메모리 덤프 및 windbg 분석 개요 [3]
11838정성태3/7/201916738.NET Framework: 811. (번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes [1]파일 다운로드1
11837정성태3/6/201926343기타: 74. 도서: 시작하세요! C# 7.3 프로그래밍 [10]
11836정성태3/5/201914298오류 유형: 525. Visual Studio 2019 Preview 4/RC - C# 8.0 Missing compiler required member 'System.Range..ctor' [1]
... 61  62  63  64  65  66  67  68  69  70  [71]  72  73  74  75  ...