[lldb-dev] Exported symbols from LLDB build products

[Greg Clayton via lldb-dev]

> On Aug 14, 2015, at 11:04 AM, Bruce Mitchener <bruce.mitchener at gmail.com> wrote:
> 
> I was doing some more digging into this and experimentation and found that the Windows build appears to handle this already, but that's because symbol visibility is different over there.
> 
> It looks like on non-Windows, we should be using the __attribute__((visibility("hidden"))) for pretty much all of the LLDB classes, apart from the public API. With that set up correctly, we don't need linker flags at all, and it gives the compiler additional information to generate better code (which linker options / scripts won't provide).
> 
> llvm's include file llvm/Support/Compiler.h provides a preprocessor definition LLVM_LIBRARY_VISIBILITY which can be applied to everything that is supposed to be internal.  This is what clang and LLVM do to hide some things, but they provide a much broader API than LLDB does.
> 
> Would you be averse to LLVM_LIBRARY_VISIBILITY being added to all of our internal class definitions? (I don't mind doing the work.)  That seems like the better and more correct way to handle this.

I would rather not do this because with all of the current work going into abstracting TypeSystem's so that they are pluggable so we can support multiple languages, we might end up making an extra lldb_internal.so that exports all lldb_private::* so that we can actually make directories that can be checked out from other repositories so that we can make dynamic plug-ins for languages that can be just inserted into the LLDB code base and will just compile. These would link against the internal LLDB code and the API for this would be expected to constantly change, there would be no guarantee of API compatability. We can't do dynamic plug-ins through our public interface (lldb::*). This would mean that LLDB.framework or lldb.so would link against this lldb_internal.so along with any dynamic plug-ins.

This might mean that we have a clang.so which completely encapsulates a Language plug-in that links against the internal lldb_private::* functions, but the shared library boundary can be used to hide different versions of llvm and clang. Think about one language plug-in that has its own copy of llvm::* and clang::*, but doesn't export any llvm or clang symbols like "clang.so", and another like "swift.so" that also contains a full copy of llvm and clang (different revisions of llvm or clang that found in clang.so). All llvm/clang code is hidden behind the shared library boundary with nothing from llvm/clang exported. I doubt we will go this way, but with all the work going on right now to make this happen we need to keep this option open. So please don't decorate any classes. It should be up to the build system to determine how the files are used, not up to classes to pre-determine this. Especially since the llvm/clang/lldb build system makes a bunch of static libraries (.a files), we really don't want to pre-bake any notions of how the code is to be used. This is a job for the linker.

> 
> If we can do that, we'd want to include "llvm/Support/Compiler.h" in just about everything to pick up the LLVM_LIBRARY_VISIBILITY definition. Would we be able to put that in one of the LLDB headers that is already included everywhere?

So I would prefer to use linker flags to control exports for now if we can. I know windows uses the declspec(__dllexport) to do this, but I do prefer to do this after the fact with linker flags if we can get away with it.

Greg