[Windows] Registry static data members not exported by extract_symbols.py, breaking plugin support in static builds

[zond]

Description

When building LLVM statically (the default configuration) on Windows with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON, external plugins cannot register themselves through llvm::Registry<clang::PluginASTAction>.

Root Cause

The extract_symbols.py script, which is used to determine which symbols to export from the statically-linked executable, filters out the Registry static data members (Head and Tail) because they don't match the function signature patterns that the script looks for.

These static data members are essential for the plugin registry to work - they form the linked list that stores registered plugins.

Affected Configuration

• Build type: Static LLVM builds (the default when BUILD_SHARED_LIBS is not explicitly set to ON)
• Plugin support flag: LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON
• Platform: Windows
• Affected versions: LLVM 19 (maybe?), 20, 21, and main branch

Impact

External plugins (like Firefox's clang-plugin) cannot register through the standard llvm::Registry mechanism, breaking plugin functionality.

Solution

Modify extract_symbols.py to recognize and export Registry static data members by adding pattern matching for mangled symbols like:

• ?Head@?$Registry@<template_args>@llvm@@
• ?Tail@?$Registry@<template_args>@llvm@@

Note: When both LLVM and the plugins are built with /Zc:dllexportInlines-, the static methods (add_node(), begin()) are inlined by the plugin at call sites, so only the data symbols need to be exported.

Reproduction

This issue was discovered while enabling Clang 20 support for Firefox's clang-plugin on Windows. The plugin builds successfully but cannot register itself because the Registry symbols are not exported from clang.exe.

Related

• Initial investigation started in Mozilla Bug 1941482
• Patch proposed in PR [Windows] Fix Registry static data members not exported by extract_symbols.py in static builds with plugin support #163391

[AaronBallman]

CC @compnerd

[compnerd]

The def file based solution is something beyond what I am familiar with and have looked into. IMO we should simply be removing the extract_symbols.py script and not supporting that mechanism. If the annotations are incorrect, we should fix those instead.

[zond]

Hey @compnerd, nice to see you in this issue as well :D

I'm honestly also far outside my comfort zone here - I just kept debugging until I found a solution that worked.

If the def file solution should be deprecated then I guess another solution should be used, but I have no idea what that would be.

What do you suggest? If nobody has a better solution, and the def file one is the one actually used right now, would it be OK to fix it so that it actually works for now - until a better solution is found?

[compnerd]

Oh, I don't have any issues with someone adjusting the def file for the export list, but I think that we should be moving towards the use of the dllstorage attributes instead. That should allow us to have a uniform source of truth: the source code. Additionally, it avoids the need to decorate and undecorate the symbols to work with them in the def file.

[zond]

Oh, I don't have any issues with someone adjusting the def file for the export list, but I think that we should be moving towards the use of the dllstorage attributes instead. That should allow us to have a uniform source of truth: the source code. Additionally, it avoids the need to decorate and undecorate the symbols to work with them in the def file.

Does this mean you're fine with my suggested solution? :D