to post messages and comments.

← Все записи с тегом SEH

@OCTAGRAM:

Самая проблемная (как сейчас представляется) часть совмещения библиотек для разных OS — это исключения и сигналы, которые конвертируются в исключения разных языков программирования. Виндоуз в этом плане очень продумана, по крайней мере, 32-разрядная и более поздние. Там общая для всех языков программирования система структурной обработки исключений (SEH), поэтому самое сложное, что там нужно делать — это брандмауэр исключений. Например, в ActiveX объектах такое есть. Исключение ловится, конвертируется в информацию IErrorInfo, передаётся в COM, а функция возвращает неуспешный HRESULT. Потом, по другую сторону можно обратно сконструировать исключение другого языка программирования.

Но нас интересуют операционные системы вроде Линукса и БиЭсДи, и там всё гораздо сложнее из-за того, что функционал структурной обработки исключений отдан на откуп компиляторам, а ядро вызывает сигналы. А компиляторы — кто в лес, кто по дрова. Они заточены под то, что вся программа написана на одном языке программирования, и код инициализации ставит обработчики сигналов для всей программы, и только так оно работает, а возможность комбинировать разные языки программирования не учтена.

@OCTAGRAM:

SEH_Init

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 не делается, так что какая разница, что внутри.