You `throw`; I'll `try` to `catch` it @ using std::cpp 2026

During 03/16/2026 to 03/18/2026, the 11th edition of the using std::cpp conference took place at the UC3M High Polytechnic School, Madrid. For this year, I prepared a talk on the internals of C++ EH (exception handling). Do you have an approximate idea of what happens when you throw an exception object? How much support is needed by the runtime? Does it work on all platforms the same? Are exceptions as slow as I heard? How is it possible for the runtime to know where to continue execution and which destructors need to be called? How do exceptions relate to runtime type identification (RTTI)? Is it possible at all to have -fexceptions with -fno-rtti?

In this talk, I tapped the exception handling parts in the Itanium ABI, LSB (Linux Standard Base), DWARF CFI (Call Frame Information), etc., and how all the pieces fit together, including a step-by-step case study where an exception is thrown and we followed stack unwinding until reaching a ‘catch’ landing pad. The recording is available here and the supporting material is here.

In the presentation, I said that a C++ program can be seen as three different programs: one that runs at compile time, one that runs at run time, and (if using DWARF CFI) one that unwinds the stack from a given point in the execution. However, during the talk and for the sake of time, I only mentioned a few simple DWARF CFI opcodes (namely, DW_CFA_def_cfa, DW_CFA_def_cfa_offset, DW_CFA_advance_loc, and DW_CFA_offset). This was sufficient for the talk, and most CFI instruction sequences look like that. Nevertheless, the DWARF standard allows for much more complex ‘programs’. The canonical frame address (CFA) and/or how registers are restored can be specified via DWARF expressions (see DWARF5, Section 2.5.1 General Operations). Such a mechanism allows for somewhat powerful expression evaluation, and simple branching (see Section 2.5.1.5 Control Flow Operations). Although some restrictions apply (see Section 6.4.2, Call Frame Instructions), this is intentionally quite flexible in order to support a wide range of situations and target architectures; however, it may also have several implications, e.g. for security and RE. It is left as an exercise for the reader to experiment and discover what can be done in this regard.

Happy hacking !