> On Aug 14, 2015, at 11:04 AM, Bruce Mitchener <bruce.mitche...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
