FB does not support exceptions anyways, so in theory the exception handling mechanism used by the underlying GCC toolchain does not matter.
In practice though, DWARF-2 GCC generates static data for stack unwinding which is put into
.eh_frame sections. The problem is that
.eh_frame data is generated also for C code (not just C++ code) like all the FB/GCC/MinGW runtime libraries, and it increases .exe size noticably. This can be avoided in multiple ways:
- Use gcc flags to disable the generation of the .eh_frame data. FB is using this in its makefile and for -gen gcc, however obviously it does not affect the prebuilt MinGW/GCC libraries (unless the entire toolchain is rebuilt).
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables
- Discard/strip the .eh_frame section when linking (by using a custom ldscript)
- Use an SJLJ toolchain (i.e. MinGW-w64 built for SJLJ, instead of MinGW.org)
Furthermore, the exception handling method may be an important detail afterall (even if you do not care about .exe size) if you want to use C++ libraries from FB, in case the C++ library uses exceptions.