[llvm] [JITLink][AArch32] Add explicit visibility macros to functions needed by unittests (PR #116557)
Saleem Abdulrasool via llvm-commits
llvm-commits at lists.llvm.org
Wed Dec 11 23:26:11 PST 2024
compnerd wrote:
@lhames it seems reasonable at first glance, but quickly breaks down.
Let's say that we are building LLVMSupport as a DLL and LLVM statically. However, because `LLVM_TEST_ABI` is defined once and doesn't consider the target's build type into consideration, we end up with:
```c
#if defined(LLVMSupport_STATIC)
#define LLVM_TEST_ABI /**/
#else
#if defined(LLVMSupport_EXPORTS)
#define LLVM_TEST_ABI __declspec(dllexport)
#else
#define LLVM_TEST_ABI __declspec(dllimport)
#endif
#endif
```
Now, when we build LLVM as a static library, `LLVMSupport_STATIC` is not defined (because it was built dynamically), and because LLVMSupport is not being built here, `LLVMSupport_EXPORTS` is undefined. So you end up with `LLVM_TEST_ABI` as `__declspec(dllimport)`, which says that the definitions that LLVM is exporting for use in test are defined elsewhere.
Because the behaviour of the `*_ABI` macro is dependent on the module being built and how that module is being built, we cannot easily just use a single definition.
Now, maybe, we can get LLVM down to the small enough surface that we can have only 2 libraries (LLVMSupport and LLVM where the second one has ALL architectures enabled and is sufficient to be used for all tools and still is well under 64K entry points including data as part of the ABI). In such a case, yes, it seems reasonable to have two test ABI macros.
My concern is that we might end up having to extract each architecture backend into a separate DLL and then have the optimizations be pulled out, the assembler pulled out, and suddenly you have a set of test ABI macros.
https://github.com/llvm/llvm-project/pull/116557
More information about the llvm-commits
mailing list