C/C++ - ARM64로 포팅할 때 유의할 점
근래에 Visual C++ Linux 프로젝트 하나를 ARM64 환경으로 포팅했는데요, 윈도우 환경에서 Linux 환경으로 포팅할 때보다는 확실히 쉬웠습니다. ^^
우선, 빌드 자체가 기존 소스코드 그대로 ARM64 환경에서 오류 하나 없이 빌드되었기 때문에 다양한 API 사용에 대한 소스코드 수정은 필요치 않았습니다. 하지만, (컴파일 오류보다 더 무서운) 실행 시 예외가 2가지 정도 발생했는데요, 그중 하나는 char 타입의 signed/unsigned 여부였습니다.
가령 아래의 코드로,
#include <iostream>
int main()
{
char v1 = 216;
printf("v1: %d, sizeof(char): %zu\n", v1, sizeof(char));
}
x64 환경에서 빌드하면 이렇게 출력이 나오지만,
$ ./bin/x64/Debug/ConsoleApplication2.out
v1: -40, sizeof(char): 1
ARM64 환경에서 빌드하면 (-40이 아닌) 216이 출력됩니다.
$ ./bin/ARM64/Debug/ConsoleApplication2.out
v1: 216, sizeof(char): 1
이에 대해 검색해 보면 ARM64 환경에서 성능상의 이유로 char가 unsigned로 처리된다고 합니다.
is char signed or unsigned by default on iOS?
; https://stackoverflow.com/questions/20576300/is-char-signed-or-unsigned-by-default-on-ios
In most cases, char is unsigned on ARM (for performance reasons) and signed on other platforms.
하지만, 이게 ARM64 환경의 잘못이라기보다는 원래 C 표준 자체가 char 타입에 대해 signed/unsigned를 선택할 수 있도록 했기 때문이라고 합니다.
What causes a char to be signed or unsigned when using gcc?
; https://stackoverflow.com/questions/46463064/what-causes-a-char-to-be-signed-or-unsigned-when-using-gcc
위의 덧글에 나온
C11 표준뿐만 아니라, 근래에 나온 표준 문서인 n3301에도,
n1570 - ISO/IEC 9899:201x
; http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
n3301 - ISO/IEC 9899:202y
; https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3301.pdf
이렇게 명시하고 있습니다.
6.2.5 Types
20. The three types char, signed char, and unsigned char are collectively called the character types.
The implementation shall define char to have the same range, representation, and behavior as either
signed char or unsigned char.
CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the
two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.
따라서, 무심코 char 타입을 signed로 가정한 모든 소스코드에서 버그가 발생할 수 있는데요, 이를 해결하려면 1) 모든 소스코드에 사용한 char 타입을 signed/unsigned를 구분해 명시하거나, 2) 컴파일러 옵션을 사용하여 char의 부호 유무에 대한 기본값을 명시하는 방법으로 해결할 수 있습니다.
당연히, 두 번째 선택이 편하고 안전합니다. gcc의 경우 그에 해당하는 옵션을 제공하는데요,
-fsigned-char
-funsigned-char
Visual C++ 프로젝트라면 다음과 같이 "Command Line"을 통해 "-fsigned-char"를 직접 명시해 주면 됩니다.
(위의 화면에서는 "Configuration"을 "Debug"로 설정했는데, 당연히 "Release"도 함께 설정해야 합니다.)
그다음 문제는, x86/x64 빌드를 모두 지원하는 C/C++ 프로젝트에서 발생할 수 있는 유형인데요, 보통 Windows/Linux 환경만을 대상으로 했다면 64비트/32비트 환경만을 구분하면 되기 때문에 전처리 변수를 _AMD64_ 또는 _X86_으로만 사용했을 것입니다.
#if defined(_AMD64_)
// 64비트 환경의 코드
#else
// 32비트 환경의 코드
#endif
그나마 "_X86_"으로 했다면 상관없지만, "_AMD64_"로 했다면 위의 소스코드를 ARM64 환경에서 빌드하는 경우 "// 32비트 환경의 코드"가 빌드돼 버그가 발생합니다.
따라서, 이제는 ARM64를 고려하도록 다음과 같이 변경해야 합니다.
#if defined(_AMD64_) || defined(_ARM64_)
// 64비트 환경의 코드
#else
// 32비트 환경의 코드
#endif
제 경우에는, 위의 2가지만 수정했더니 ARM64 환경에서도 C/C++ 프로젝트가 잘 동작했습니다.
마지막으로, ARM64의 경우 대체로 Little-Endian을 쓰는 듯하지만, 그래도 원칙은 Bi-Endian을 지원하는 환경이니만큼 혹시 모르니 Endian 체크도 하면 좋을 듯합니다. ^^
#include <cstdio>
#include <limits.h>
bool IsLittleEndian()
{
int x = 1;
return *(char*)&x == 1;
}
int main()
{
signed char v1 = 216;
printf("v1: %d, sizeof(char): %zu, is little-endian: %d\n", v1, sizeof(char), IsLittleEndian());
return 0;
}
이 외에, 기타 (다행히 제 경우에는 해당하지 않았지만) 뭔가 빠진 부분이 있을 수도 있는데요, 혹시 이에 대한 경험이 있으신 분들은 ^^ 덧글로 재미있는 썰을 부탁드립니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]