SEH_Init
Теперь понятно, что имеет в виду @vt под «знает, как компилировать под Windows». Если считать Microsoft законодателем мод, то что-то в этом есть, хотя как по мне, — скорее вкусовщина. По-любому, без брандмауэров исключений никакой работы с COM не делается, так что какая разница, что внутри.
On x86_64 windows exception mechanism is no more based on a chained list of handlers addresses on the stack. Instead unwinding information is used to retrieve the exception handler (similar to ZCX GCC mechanism). So in order to register an exception handler we need to put in the final executable some unwinding information. This information might be present statically in the image file inside the .pdata section or registered through RtlAddFunctionTable API. Currently the GCC toolchain does not generate the .pdata information for each function. As we don't need to handle SEH exceptions except for signal handling we are registering a "fake" unwinding data that associate a SEH exception handler to the complete .text section. As we never return from the handler, the system does not try to do the final unwinding using the pdata information. The unwinding is handled by the runtime using either the GNAT SJLJ mechanism or the ZCX GCC mechanism. The current implementation is using the RtlAddFunctionTable.
Here is for information purposes the equivalent using a static .pdata section: …
Теперь понятно, что имеет в виду @vt под «знает, как компилировать под Windows». Если считать Microsoft законодателем мод, то что-то в этом есть, хотя как по мне, — скорее вкусовщина. По-любому, без брандмауэров исключений никакой работы с COM не делается, так что какая разница, что внутри.
