Hmm, while the below would help, it wouldn't prevent the llvm and clang
symbols from being re-exported from the LLDB shared library.
I still think it would be good to do, but we'd still need the linker
options (but that's easy for Darwin, a bit more involved for Linux and
FreeBSD, I think).
- Bruce
On Sat, Aug 15, 2015 at 1: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.
>
> 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?
>
> - Bruce
>
>
> On Fri, Aug 14, 2015 at 11:14 PM, Greg Clayton <gclay...@apple.com> wrote:
>
>>
>> > On Aug 13, 2015, at 6:43 PM, Bruce Mitchener via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Hello,
>> >
>> > On Mac OS X, when using the xcode projects, there is some machinery to
>> manage what symbols are exported from various things:
>> >
>> > • liblldb only exports the public API.
>>
>> It currently exports:
>>
>> _ZN4lldb*
>> _ZNK4lldb*
>> init_lld*
>>
>>
>> > • debugserver only exports _DNB* and __DNB*
>>
>> That is due to legacy stuff and debugserver actually doesn't need to
>> export anything...
>>
>> > • argdumper exports nothing
>> > • lldb-server exports nothing
>>
>> No executable tools need to ever really export anything, so this can and
>> should almost always be the rules we use in CMake to create executables,
>> not shared libraries, but just executables.
>>
>> > This machinery only exists within the xcode projects though and isn't
>> used in the cmake or autotools build systems.
>>
>> We should fix this.
>>
>> > I'm not interested in adding it to the autotools build system, but I
>> would like to get this set up in the cmake build system.
>> >
>> > The LLVM cmake code provides a helper function for managing this
>> already in a cross-platform manner. The main difference is that it expects
>> one fewer leading underscores in the exports files and a particular naming
>> scheme for the files.
>> >
>> > Managing the files and their names is pretty easy and I can handle that.
>> >
>> > The other difference is a bit harder to manage unless we set up a
>> script to run in the xcode build to perform the mapping (not hard for
>> someone that knows xcode, I guess).
>>
>> Why? The
>> http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports
>> file is so simple and it won't change. I don't see the need to do anything
>> special in Xcode to convert some random file into another format.
>>
>> >
>> > So:
>> >
>> > • Is this something we want on all platforms? I think the most
>> important of these is limiting liblldb to only exporting the public API.
>>
>> The lldb.so should limit its exports. It makes the shared library cleaner
>> and easier for the dynamic loaders to deal with.
>> > • Should any other targets have their exported symbols similarly
>> restricted? (Perhaps lldb-mi?)
>>
>> lldb-mi should export nothing just like argdumper and lldb-server.
>>
>> > • Is someone willing to assist with a minor xcode change so that
>> we don't have to have a separate copy of 2 of the files for the xcode build?
>>
>> I am not sure how this would work. I would rather not have something
>> generating the
>> http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports
>> file as these files aren't too difficult to create, even if there are two
>> copies. It currently contains:
>>
>> __ZN4lldb*
>> __ZNK4lldb*
>> _init_lld*
>>
>> These could easily be added to the linker flags for command line builds
>> and they aren't going to be changing. So I don't see the need to jump
>> through any hoops to make this happen since they won't change. Just make it
>> happen in our CMake/make builds.
>>
>> Greg
>>
>>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
