Microsoft MVP성태의 닷넷 이야기
VC++: 138. x64 빌드에서 extern "C"가 아닌 경우 ___cdecl name mangling 적용 [링크 복사], [링크+제목 복사],
조회: 20915
글쓴 사람
정성태 (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]

... 46  [47]  48  49  50  51  52  53  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12796정성태8/21/202118749.NET Framework: 1099. C# 10 - (4) 상수 문자열에 포맷 식 사용 가능파일 다운로드1
12795정성태8/20/202118674.NET Framework: 1098. .NET 6에 포함된 신규 BCL API - 스레드 관련
12794정성태8/20/202118378스크립트: 23. 파이썬 - WSGI를 만족하는 최소한의 구현 코드 및 PyCharm에서의 디버깅 방법 [1]
12793정성태8/20/202118796.NET Framework: 1097. C# 10 - (3) 개선된 변수 초기화 판정파일 다운로드1
12792정성태8/19/202120402.NET Framework: 1096. C# 10 - (2) 전역 네임스페이스 선언파일 다운로드1
12791정성태8/19/202116838.NET Framework: 1095. C# COM 개체를 C++에서 사용하는 예제 [3]파일 다운로드1
12790정성태8/18/202121021.NET Framework: 1094. C# 10 - (1) 구조체를 생성하는 record struct파일 다운로드1
12789정성태8/18/202119885개발 환경 구성: 597. PyCharm - 윈도우 환경에서 WSL을 이용해 파이썬 앱 개발/디버깅하는 방법
12788정성태8/17/202117261.NET Framework: 1093. C# - 인터페이스의 메서드가 다형성을 제공할까요? (virtual일까요?)파일 다운로드1
12787정성태8/17/202117652.NET Framework: 1092. (책 내용 수정) "4.5.1.4 인터페이스"의 "인터페이스와 다형성"
12786정성태8/16/202119758.NET Framework: 1091. C# - Python range 함수 구현 (2) INumber<T>를 이용한 개선 [1]파일 다운로드1
12785정성태8/16/202118061.NET Framework: 1090. .NET 6 Preview 7에 추가된 숫자 형식에 대한 제네릭 연산 지원 [1]파일 다운로드1
12784정성태8/15/202118045오류 유형: 757. 구글 메일 - 아웃룩에서 메일 전송 시 Sending' reported error (0x800CCC0F, 0x800CCC92)
12783정성태8/15/202115571.NET Framework: 1089. C# - Indexer에 Range 및 람다 식을 이용한 필터 구현 [1]파일 다운로드1
12782정성태8/14/202115219오류 유형: 756. 파이썬 - 윈도우 환경에서 pytagcloud의 한글 출력 방법
12781정성태8/14/202117445오류 유형: 755. 파이썬 - konlpy 사용 시 JVM과 jpype1 관련 오류
12780정성태8/13/202116165.NET Framework: 1088. C# - 버스 노선 및 위치 정보 조회 API 사용을 위한 기초 라이브러리 [2]
12779정성태8/13/202118574개발 환경 구성: 596. 공공 데이터 포털에서 버스 노선 및 위치 정보 조회 API 사용법
12778정성태8/12/202114652오류 유형: 755. PyCharm - "Manage Repositories"의 목록이 나오지 않는 문제
12777정성태8/12/202116549오류 유형: 754. Visual Studio - Input or output cannot be redirected because the specified file is invalid.
12776정성태8/12/202115127오류 유형: 753. gunicorn과 uwsgi 함께 사용 시 ERR_CONNECTION_REFUSED
12775정성태8/12/202128908스크립트: 22. 파이썬 - 윈도우 환경에서 개발한 Django 앱을 WSL 환경의 gunicorn을 이용해 실행
12774정성태8/11/202118566.NET Framework: 1087. C# - Collection 개체의 다중 스레드 접근 시 "Operations that change non-concurrent collections must have exclusive access" 예외 발생
12773정성태8/11/202117991개발 환경 구성: 595. PyCharm - WSL과 연동해 Django App을 윈도우에서 리눅스 대상으로 개발
12772정성태8/11/202118380스크립트: 21. 파이썬 - 윈도우 환경에서 개발한 Django 앱을 WSL 환경의 uwsgi를 이용해 실행 [1]
12771정성태8/11/202117001Windows: 196. "Microsoft Windows Subsystem for Linux Background Host" / "Vmmem"을 종료하는 방법
... 46  [47]  48  49  50  51  52  53  54  55  56  57  58  59  60  ...