C++ Exception Basics

TL;DR

  • C++ 예외 처리는 Itanium C++ ABI의 규칙을 따른다.

  • 정상 경로는 비용이 없고(=zero-cost), 예외가 던져질 때만 스택 언와인딩이 수행된다.

  • 언와인딩은 DWARF 언와인드 정보(.eh_frame) 를 이용하여 스택 프레임을 한 단계씩 되돌리며,
    프레임마다 personality 함수가 “catch 대상인지/정리만 할지”를 판단한다.

  • 예외 객체는 heap 에 만들어지며 reference count 로 생명주기를 관리한다.

  • 언와인딩 과정에서 callee-saved 레지스터만 복원되고, caller-saved 레지스터는 필요 시 landing pad 코드가 재구성한다.

  • 성능 병목은 동적 라이브러리 목록을 보호하는 전역 로더 락과 .eh_frame 탐색 비용이며,
    언와인더 구현체(libgcc_s, LLVM libunwind 등)는 이를 캐싱 전략으로 최적화한다.

Overview

1) 예외 발생 시 전체 흐름

  1. throw → 컴파일러가 생성한 코드가 예외 객체를 heap에 할당하고 __cxa_throw 호출

  2. __cxa_throw → Itanium ABI의 _Unwind_RaiseException 호출

  3. 언와인더가 현재 스택 프레임 위치에서 DWARF CFI(unwind info) 를 읽는다

  4. 1단계(Search phase)

    • 각 프레임마다 personality 함수를 호출해
      “이 프레임이 이 예외를 잡을 수 있는가?” 검사

  5. 2단계(Cleanup phase)

    • 다시 처음부터 프레임을 순회하며

      • destructor 호출

      • catch 대상 프레임까지 스택 롤백

    • 도착하면 landing pad로 점프

  6. landing pad에서 __cxa_begin_catch 실행 → 예외 객체 참조 획득

  7. catch 블록 종료 시 __cxa_end_catch 호출 → refcount 감소 및 필요 시 삭제

2) Itanium C++ ABI가 보장하는 것

  • 예외 객체 메모리 레이아웃

  • __cxa_throw, __cxa_begin_catch, __cxa_end_catch, __gxx_personality_v0 등의 인터페이스

  • personality 함수가 수행해야 하는 동작과 판단 규칙

  • DWARF 기반 스택 언와인딩 절차
    → 컴파일러(gcc/clang)가 달라도 예외 모델은 호환됨

3) DWARF 언와인드 정보(.eh_frame)

  • 각 함수의 스택 레이아웃 변화, 프롤로그/에필로그에서 저장된 레지스터 위치 등을 기록한 metadata

  • 언와인더는 이를 해석하여 “이전 프레임의 SP/IP/FP/저장 레지스터”를 복원할 수 있다

  • 예외 처리 전용이며, 디버그 정보(.debug_info)와는 별개

4) personality 함수

프레임마다 호출되는 “언어별 처리 엔진” 역할.

  • C++: __gxx_personality_v0

  • 책임

    1. 이 프레임이 해당 예외 타입을 catch할 수 있는지 판단

    2. cleanup-only 영역인지 판단

    3. landing pad의 위치(IP)를 언와인더에 알려줌

5) 레지스터 복원 규칙

  • callee-saved 레지스터만 DWARF를 통해 반드시 복원

    • (예: x86-64: RBX, RBP, R12~15 등)

  • caller-saved는 landing pad 코드가 직접 필요 시 다시 로딩

  • SP, IP(PC), FP 같은 프레임 관련 레지스터는 항상 언와인더가 복원

6) 성능 병목과 최적화

  • 동적 라이브러리 목록은 로더의 전역 락(dl loader lock) 으로 보호됨
    → .eh_frame 위치 탐색 시 락 획득 필요

  • 대규모 프로그램에서 예외 비용이 급증하는 이유

    • 프레임마다 DWARF를 파싱

    • 잦은 전역 락 획득

  • LLVM libunwind, libgcc_s 등은

    • IP → CFI 캐싱

    • 함수 단위 또는 호출 지점 단위 캐싱

    • backtrace fast path 최적화
      등을 사용해 성능 개선

Example (개념 흐름 예시)

예외 발생 → __cxa_throw
→ _Unwind_RaiseException
→ Frame N personality 검사(부적합)
→ Frame N–1 personality 검사(부적합)
→ Frame N–2 personality 검사(catch 가능 → search phase 종료)
→ cleanup phase 시작(위 프레임들 destructor 실행)
→ landing pad IP로 점프
→ __cxa_begin_catch
→ catch 블록 실행
→ __cxa_end_catch → refcount 0 → 예외 객체 delete

Takeaways

  • C++ 예외 처리는 zero-cost 모델이며, 실행 중 예외가 없을 때 비용이 사실상 없다.

  • 언와인딩은 DWARF + Itanium ABI + personality 함수의 조합으로 동작한다.

  • 예외 객체는 heap에 있으며 refcount로 생명주기 관리된다.

  • caller-saved / callee-saved 구분은 언와인딩 비용 최적화를 위해 중요하다.

  • 동적 라이브러리 환경에서는 로더 락 경쟁이 예외 비용을 악화시킬 수 있으며,
    현대 언와인더는 이를 캐싱 전략으로 완화한다.

  • GCC/Clang 등 서로 다른 C++ 런타임이라도 Itanium ABI를 준수하는 한 상호 운용 가능하다.

References

CppCon 2017: Dave Watson “C++ Exceptions and Stack Unwinding” C++ Exceptions for Smaller Firmware - Khalil Estell - CppCon 2024