[llvm] [ORC] Use __unw_add_dynamic_eh_frame_section/__unw_remove_dynamic_eh_ frame_section in RegisterEHFrames.cpp (PR #212260)

[via llvm-commits]

================
@@ -122,6 +127,14 @@ Error walkLibunwindEHFrameSection(const char *const SectionStart,
 
 Error registerEHFrameSection(const void *EHFrameSectionAddr,
                              size_t EHFrameSectionSize) {
+#if defined(HAVE_REGISTER_FRAME) && defined(HAVE_DEREGISTER_FRAME) &&          \
----------------
mkovacevic99 wrote:

Yes, there's a real use-case, and it's MinGW, not MSVC. MinGW builds using the older "dw2" exception model get HAVE_REGISTER_FRAME/HAVE_DEREGISTER_FRAME defined (libgcc provides __register_frame/__deregister_frame there), so this code path isn't skipped on that target — it's a real Windows toolchain that hits it.

And that exposes a real problem with the current guard: LLVM_ATTRIBUTE_WEAK is a no-op on all of _WIN32, including MinGW (see the FIXME: Provide this for PE/COFF targets right next to its definition in [llvm\include\llvm\Support\Compiler.h:310]). So on a MinGW dw2 build, my "weak" declarations of __unw_add_dynamic_eh_frame_section/__unw_remove_dynamic_eh_frame_section silently become hard requirements — and MinGW's dw2 runtime (libgcc) doesn't actually provide that symbol (it's a libunwind thing). So as written, this would fail to link on a real MinGW dw2 build, not just be redundant code. Good catch.

Excluding only MSVC wouldn't fix this either, for the same reason — MinGW would still hit the broken weak declaration.

Fix: I'll stop relying on weak declarations here and add a proper configure-time check instead — check_symbol_exists(__unw_add_dynamic_eh_frame_section ...) → HAVE_UNW_ADD_DYNAMIC_EH_FRAME_SECTION, following the same pattern already used for HAVE_UNW_ADD_DYNAMIC_FDE. That'll correctly come back "no" on MinGW dw2 and skip the code cleanly instead of failing to link.

https://github.com/llvm/llvm-project/pull/212260