Support clang plugins on Windows (original) (raw)

January 20, 2024, 6:37pm 1

Description of the project: The Clang compiler is part of the LLVM compiler infrastructure and supports various languages such as C, C++, ObjC and ObjC++. The design of LLVM and Clang allows the compiler to be extended with plugins[1]. A plugin makes it possible to run extra user defined actions during a compilation. Plugins are supported on unix and darwin but not on windows due to some specifics on the windows platform.

The general work that needs to be done is to annotate all the public API surface with __declspec(dllexport) and similar if they are being built as a dynamically linked library (and nothing if being built statically). When the library is being consumed the attribute on the same declaration must be __declspec(dllimport) or the same spelling for the GNU version for ELF and MachO. Note that the attribute changes between the implementation and consumer and between static and dynamic linking. This is normally controlled by expansion to a macro.

Expected result: This project aims to allow make clang -fplugin=windows/plugin.dll work. The implementation approach should extend the working prototype [3] and extend the annotation tool [4]. The successful candidate should be prepared to attend a weekly meeting, make presentations and prepare blog posts upon request.

Further reading [1] https://clang.llvm.org/docs/ClangPlugins.html

[2] https://discourse.llvm.org/t/clang-plugins-on-windows

[3] https://github.com/llvm/llvm-project/pull/67502

[4] https://github.com/compnerd/ids

**Project size:**Either medium or large.

Difficulty: Medium

Confirmed Mentor: Vassil Vassilev,Saleem Abdulrasool

Mohamed January 23, 2024, 10:41am 2

Hi @vvassilev,
what are the required skills for this project?
and what are the areas of LLVM that I will work on If I get accepted?

Thanks

vvassilev January 23, 2024, 10:44am 3

Hi @Mohamed,

@compnerd would be probably better at answering that. I think one needs to know well windows, its linking model and to have experience with low-level tools. You will be working mostly on the llvm and clang codebases.

Best, Vassil

Hi @compnerd @vvassilev in order for a proposal to be credibile which specific parts of the codebase woud you want me to contribute to? Any tips youcould share with me would be great.
Thanks

compnerd February 19, 2024, 2:28pm 5

Yes, definitely would be helpful to have an understanding of low-level tools, in particular, link, objdump, llvm-readobj, ar, as well as object file formats, at the very least ELF and COFF, MachO is likely a good thing. More than knowing Windows, I would say that an understanding of Unix is likely helpful too.

I would say that LLVM, clang, LLDB, and LLD codebases are the ones to expect to be involved in.

compnerd February 19, 2024, 2:30pm 6

I would say at the very least, LLVM, but I wouldn’t be surprised if it crosses across clang, clang tools extras, and lldb.

fsfod March 4, 2024, 4:58pm 7

@tstellar did you ever publish your changes to compnerd’s ids tool anywhere? and what was the issue you were having that you disabled LLVM_CLASS_ABI for windows?

tstellar March 4, 2024, 11:15pm 8

fsfod March 5, 2024, 2:50pm 9

So explicitly deleted copy constructor and assignment operators need to be generated for classes with non copyable data so dllexport doesn’t try to instantiate them?

tstellar March 5, 2024, 4:59pm 10

I think that’s right. It’s a lot hard to do than it sounds, though. But I wouldn’t object if someone wanted to try.

tstellar March 21, 2024, 10:19pm 11

Here is my fork of ids: GitHub - tstellar/ids at annotate-classes

And the script I used to run it:

for f in `find /home/fedora/llvm-project/clang/lib/ /home/fedora/llvm-project/llvm/tools/ /home/fedora/llvm-project/llvm/unittests/ /home/fedora/llvm-project/lld/ /home/fedora/llvm-project/lldb/ -iname '*.cpp' -o -iname '*.c'`; do \
  echo $f;
  ./build/bin/idt -p /home/fedora/llvm-project/abi-build/ $f  --extra-arg "-I/home/fedora/llvm-install/lib/clang/17/include/" --extra-arg '-DLLVM_ABI=__attribute__((__visibility__("default")))' --extra-arg '-fvisibility=hidden' --extra-arg '-DLLVM_FUNC_ABI=LLVM_ABI' --extra-arg '-DLLVM_CLASS_ABI=LLVM_ABI' --apply-fixits --inplace --export-macro=LLVM_ABI;
done

fsfod March 23, 2024, 5:55pm 12

@tstellar Do you think the correct fix for compile errors from templated base class functions being instantiated by dllexport even though the function is not supported in particular context is to declare them with std::enable_if? Some example classes this happens with is iterator_facade_base for llvm::sys:path::const_iterator and ilist_node_impl::isSentinel for various IR types.
A common patten seems to be that the problematic functions have a static_assert on same condition that enable_if would use.

tstellar March 23, 2024, 9:09pm 13

@fsfod You may want to look at this thread on Discord where we discussed various solutions, for example.

I’m not very knowledgeable about C++ so I can’t really offer much more insight.

I’ve given this problem a bit of work locally, and found that cmake provides WINDOWS_EXPORT_ALL_SYMBOLS. While it doesn’t cover global variables it will handle functions and classes, it reduces the diff size quite a lot. although I’m not sure if people would find it appropriate to export everything like this, especially with how many symbols llvm has and dlls hard limit of UINT16_MAX exported symbols.

fsfod March 28, 2024, 2:34pm 15

That is how the existing python script works, but as you guessed it has to workaround the DLL exported symbol limit by trying to filter down the exports based on name mangling to only export some symbol types. But it seems to have issues with missing symbols and doesn’t work for importing data symbols based on some past mailing list threads.

apache-hb September 26, 2024, 1:37pm 16

I’ve been continuing to work on this for a while and have a few changesets. I feel it would be best to start by annotating libraries bottom up. with LLVMDemangle, LLVMSupport, and LLVMOption to keep changesets small. I’ve also been annotating variables and classes that should be kept internal to these libraries as hidden to reduce export table sizes, which would be valuable even if dynamic linking doesnt make it in.