[PATCH] D109192: [WIP/DNM] Support: introduce public API annotation support

Saleem Abdulrasool via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 2 14:28:20 PDT 2021


compnerd added a comment.

In D109192#2980913 <https://reviews.llvm.org/D109192#2980913>, @tschuett wrote:

> It is completely up to you, but for me `Support` is kind of redundant or the wrong kind of information. I would expect something like `LLVM_PUBLIC_API`.

`LLVM_PUBLIC_API` is not feasible IMO as there will be a macro per dynamic library that we end up with and each must have a separate spelling [1].  I suppose I can do a bit of macro expansion magic to do something like:

  LLVM_PUBLIC_API(LLVMSupport)
  LLVM_PUBLIC_API(LLVM)
  LLVM_PUBLIC_API(LLVMObject)

where the optional parameter is the name of the dynamic object that serves as the home (assuming that we end up with `LLVMSupport.dll`, `libLLVM.dylib` and `libLLVMObject.so` in the fictional world).

[1] The separate spelling is required for cases where multiple libraries are in an address space.  Consider the following:

Library A: `A_API`
Library B: `B_API`
The executable see:

  int LLVM_PUBLIC_API f(void);
  int LLVM_PUBLIC_API g(void);
  int main() {
    return f() + g();
  }

What happens if B also depends on A?  It will incorrectly annotate the `f` as being locally defined if we use the same macro.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109192/new/

https://reviews.llvm.org/D109192



More information about the llvm-commits mailing list