Visual Studio 2015 Update 1 부터 공식적으로 clang을 지원하기 시작했는데... 간단하게 몇가지 짚어보고자 한다.

clang을 이용해서 윈도우즈 플렛폼용 바이너리 파일을 만들어 내는 방법은 크게 보면 두가지가 가능하다.

첫번째 방법은 clang/llvm 컴파일러 툴체인 소스코드를 수정해서 Itanium ABI를 사용하고, 라이브러리 파일로 MinGW 코드를
사용하는 방법이다. 이럴 경우 GCC C++ABI 와 동일한 구조를 사용하기 때문에 C++ Exception을 제약없이 사용할 수 있다.

두번째 방법은 ms compatible 모드로 clang/llvm을 사용하는 거다. 이 경우 바이너리 형태의 VC++ 라이브러리 파일을 그대로
링크해서 사용할 수 있지만 C++ABI의 상이함으로 C++ Exception 사용에 제약이 따르게 된다.

Visual C++ 컴파일러가 사용하는 C++ABI 내부구조가 공식적인 문건으로 공개되어 있는 게 아니라서 VC++ 컴파일러가 생성하는
코드를 해킹해서 C++ABI 내부구조를 알아내야하는 어려움이 따르게 된다. 현재 clang/llvm 커뮤니티에서 MS VC++ ABI의
상당 부분을 알아내서 코드로 구현해 놓고 있지만, Exception 내부 구조 까지 완벽하게 모두 알아내서 구현해 놓은 것은 아니다.

테크니칼 적인 면에서 보면 두번째 방법이 어렵다. 첫번째 방법은 Itanium ABI를 구현해 놓은 GCC 컴파일러 툴 체인 소스코드를
그대로 이용해서 참조하면 되지만, 두번째 방법의 경우 VC++ ABI 구조를 해킹으로 알아내서 구현해야 하기 때문이다.

clang을 포팅해서 상용화한 Embarcadero의 경우 쉬운 첫번째 방법을 사용하고 있다.
Itanium ABI를 사용하므로 Exception 내부 코드를 특별히 따로 구현할 필요도 없고, 파스칼 Exception 방식만 고려하면 되지만
VC++로 컴파일된 바이너리 형태의 라이브러리 파일을 그대로 링크해서 사용하는 것은, 첫번째 방식으로는 불가능 하다.


그러나 Visual Studio에서 clang/llvm을 지원하기 시작하면서 상황은 크게 달라질 것으로 보인다.

MS가 VC++ABI를 지원하는 코드를 clang/llvm 커뮤니티에 피드백 하기로 결정했으니 Visual Studio IDE 에서의 clang 코드
디버깅은 물론 C++Exception도 완벽하게 지원될 수 있기 때문이다.

clang 프론트엔드가 생성하는 SSA 형태의 llvm bit 코드를 Visual Studio C2 코드제네레이터에서 사용되는 Tuple 형태로 변환해서
사용하기 때문에 기존의 바이너리 형태의 라이브러리 사용은 물론, 디버깅, 프로파일링 등... 여러가지 툴을 그대로 이용할 수 있는
것도 장점이다.

현재는 clang 3.7을 이용하므로 몇가지 제약이 있지만, MS의 피드백을 통한 clang/llvm 지원으로 차기 빌드에선 Visual Studio
개발툴을 사용하는 환경이 더 쓸모 있어 질 듯 하다...


위와 같이... 컴파일 옵션을 적절하게 설정해주면 윈도우즈용 MFC 코드를 clang 컴파일러를 이용해서 컴파일 할 수 있다.




Visual Studio IDE에서 clang을 이용하면서 통합 디버거 사용은 물론, 리펙토링 등의 기능도 사용할 수 있다.





Visual Studio IDE에서 clang 을 이용해서 윈도우즈 MFC 코드를 컴파일해서 실행해 본 모습이다.



덧붙여서...

MS가 clang을 끌어 안은 것은 크로스 플렛폼을 위한 전략 때문이다.
다른 플렛폼에서 개발된 소스코드, 이를테면 맥에서 ObjectC 로 개발된 소스코드를 윈도우즈 플렛폼에서 재사용 한다고 할 때...
프론트엔드로 clang을 사용해서 소스코드 수정 없이 그대로 컴파일 할 수 있고, SSA 형태의 llvm bit IR을 MS 코드제네레이터인
C2에서 사용하는 tuple 형태로의 변환을 해서 코드를 생성하기 때문에 VC++로 컴파일된 바이너리 형태의 라이브러리를 링크해서
사용하는 게 가능하고 VS IDE에서 디버거, 프로파일링, InteliTrace 등의 기존의 도구들을 그대로 사용할 수 있게 된다.

실제로 MS는 맥 App용으로 개발된 소스코드를 수정 하지않고 그대로 윈도우즈 플렛폼에서 컴파일해서 실행할 수 있도록 하는 기법을
내부적으로 이미 구현해 놓은 상태다. 이게 가능한 것은 맥에서 사용되는 API를 대신할 수 있도록하는 런타임을 만들어주면 되기 때문
이다.