프로젝트를 컴파일하는 데 사용해야하는 컴파일러를 결정하기에 충분한 정보를 찾을 수 없습니다. 다른 컴퓨터에는 프로세스를 시뮬레이션하는 여러 프로그램이 있습니다. Linux에서는 GCC를 사용하고 있습니다. 모든것이 좋아. 코드를 최적화 할 수 있고, 빠르게 컴파일되고 그다지 많은 메모리를 사용하지 않습니다.
MSVC 및 GCC 컴파일러를 사용하여 자체 벤치 마크를 수행합니다. 나중에 하나는 약간 빠른 바이너리를 생성합니다 (각 서브 아키텍처마다). 컴파일 시간은 MSVC 이상입니다.
그래서 MinGW를 사용하기로 결정했습니다. 그러나 MinGW에서 예외 처리 방법 및 구현에 대한 설명을 찾을 수 없습니다. 운영 체제 및 아키텍처마다 다른 배포판을 사용할 수 있습니다.
고려 사항 :
- 컴파일 시간과 메모리는 사용에 중요하지 않습니다. 중요한 것은 런타임 최적화입니다. 프로그램이 충분히 빨라야합니다. 느린 컴파일러가 허용됩니다.
- 운영체제 : Microsoft Windows XP / 7 / 8 / Linux
- 아키텍처 : Intel Core i7 / Core2 / XP : P를 실행하는 매우 오래된 i686
답변
MinGW-w64 Wiki 에는 간단한 개요가 있습니다 .
왜 mingw-w64 gcc가 Dwarf-2 예외 처리를 지원하지 않습니까?
드워프-2 EH의 Windows 용 구현은 64 비트 Windows 응용 프로그램에서 작업에 전혀 설계되지 않았습니다. win32 모드에서 예외 해제 해제 핸들러는 비 dw2 인식 코드를 통해 전파 될 수 없습니다. 이는 Visual Studio로 빌드 된 Windows 시스템 DLL 및 DLL을 포함하여 비 dw2 인식 “외부 프레임”코드를 통과하는 예외가 실패 함을 의미합니다. gcc의 드워프 -2 풀림 코드는 x86 풀기 어셈블리를 검사하여 다른 드워프 -2 풀기 정보가 없으면 진행할 수 없습니다.
예외 처리 의 SetJump LongJump 방법은 일반적인 보호 오류를 제외하고 대부분의 경우 win32 및 win64 모두에서 작동합니다. gcc의 구조적 예외 처리 지원은 dw2 및 sjlj의 약점을 극복하기 위해 개발되고 있습니다. win64에서 해제 정보는 xdata-section에 있으며 스택 대신 .pdata (함수 설명자 테이블)가 있습니다. win32의 경우 처리기 체인이 스택에 있으며 실제 실행 코드로 저장 / 복원해야합니다.
예외 처리 에 관한 GCC GNU :
GCC는 예외 처리 (EH)를위한 두 가지 방법을 지원합니다.
- DWARF-2 (DW2) EH . DWARF-2 (또는 DWARF-3) 디버깅 정보를 사용해야합니다. DW-2 EH는 큰 호출 스택 해제 테이블이 실행 파일에 포함되어야하기 때문에 실행 파일이 약간 부풀어 질 수 있습니다.
- setjmp / longjmp (SJLJ) 기반의 메소드입니다 . SJLJ 기반 EH는 DW2 EH보다 속도가 훨씬 느리지 만 (예외가 발생하지 않으면 일반 실행에도 불이익을 주지만) GCC로 컴파일되지 않았거나 콜 스택 해제 정보가없는 코드에서 작동 할 수 있습니다.
[…]
구조적 예외 처리 (SEH)
Windows는 구조적 예외 처리 (SEH)라는 자체 예외 처리 메커니즘을 사용합니다. […]
불행히도 GCC는 아직 SEH를 지원하지 않습니다. […]
또한보십시오:
답변
SJLJ (setjmp / longjmp) : – 32 비트 및 64 비트에 사용 가능 –“제로 비용”아님 : 예외가 발생하지 않더라도 약간의 성능 저하가 발생합니다 (예외 무거운 코드에서 ~ 15 %) – 예외 허용 예를 들어 창 콜백을 통과하는 것
DWARF (DW2, dwarf-2) – 32 비트 만 가능 – 영구 런타임 오버 헤드 없음 – 전체 호출 스택이 드워프 가능해야합니다. 즉, Windows 시스템 DLL과 같은 예외를 처리 할 수 없습니다.
SEH (제로 오버 헤드 예외) – 64 비트 GCC 4.8에서 사용할 수 있습니다.
출처 : http://qt-project.org/wiki/MinGW-64-bit
