自制mylib.dll引入C++异常致调用程序崩溃的原因咨询

自制的mylib.dll原本静态链接libgcc和libstdc++，近期在库内引入C++异常并全部内部捕获（不抛出给调用者），但调用它的main.exe仍会崩溃。main.exe通过以下方式链接库：

ld [args] -Wl,--start-group mylib.dll.a <other libraries> -Wl,--end-group ...

仅当mylib.dll改为动态链接标准库，或main.exe也静态链接相同标准库时，程序才能正常运行。已确定采用动态链接方案，但想了解崩溃的根本原因。

根本原因：静态链接导致的标准库多实例冲突 #

GCC的C++异常处理依赖libgcc和libstdc++中的全局状态与元数据，当DLL和主程序各自静态链接标准库时，会出现两套独立的实例，直接破坏异常处理的流程：

• 全局异常处理状态不共享：异常抛出时，需要依赖全局的异常帧链表、终止处理函数表等结构。mylib.dll静态链接的标准库拥有自己的这套结构，而main.exe的标准库实例拥有另一套。当库内抛出异常，栈展开流程可能错误地访问主程序的全局状态，或者主程序的异常处理逻辑干扰库内的展开过程，直接触发内存访问错误或断言失败。
• 栈展开元数据不兼容：栈展开依赖编译时生成的EH_FRAME段元数据，静态链接的标准库会将这部分数据嵌入到DLL内部。当异常展开需要跨模块遍历调用栈时，主程序的异常处理代码无法识别DLL内的EH_FRAME元数据，导致展开过程中断或错误，最终崩溃——哪怕异常最终会在库内被捕获，展开的初始化阶段已经触发了错误。
• 未定义行为的必然结果：C++标准明确禁止多个静态链接的标准库实例在同一进程中运行，这属于未定义行为。即使你确保异常不跨DLL抛出，异常处理的底层机制已经因为多实例冲突被破坏，崩溃是这类场景下的典型表现。

为什么动态链接或主程序也静态链接能解决问题？ #

• 动态链接标准库：此时整个进程只有一个libgcc和libstdc++的实例，所有模块共享同一套全局状态和元数据，栈展开流程可以正常跨模块执行，异常处理逻辑完全一致，自然不会崩溃。
• 主程序也静态链接相同标准库：这属于侥幸可行的未定义行为——只有当主程序和DLL使用完全相同版本的标准库、编译选项（如-fexceptions、优化等级）时，两套静态链接的标准库代码和元数据才会完全一致，异常处理流程可能暂时正常。但这依然不符合标准，跨DLL抛出异常时，可能会出现type_info地址不匹配导致catch块无法捕获异常等问题，风险极高。

内容的提问来源于stack exchange，提问作者Frederik Popp