<div dir="ltr">Hmm, while the below would help, it wouldn't prevent the llvm and clang symbols from being re-exported from the LLDB shared library.<div><br></div><div>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).</div><div><br></div><div> - Bruce<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 15, 2015 at 1:04 AM, Bruce Mitchener <span dir="ltr"><<a href="mailto:bruce.mitchener@gmail.com" target="_blank">bruce.mitchener@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div> - Bruce</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 11:14 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Aug 13, 2015, at 6:43 PM, Bruce Mitchener via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> On Mac OS X, when using the xcode projects, there is some machinery to manage what symbols are exported from various things:<br>
><br>
> • liblldb only exports the public API.<br>
<br>
</span>It currently exports:<br>
<br>
_ZN4lldb*<br>
_ZNK4lldb*<br>
init_lld*<br>
<br>
<br>
> • debugserver only exports _DNB* and __DNB*<br>
<br>
That is due to legacy stuff and debugserver actually doesn't need to export anything...<br>
<br>
> • argdumper exports nothing<br>
> • lldb-server exports nothing<br>
<br>
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.<br>
<span><br>
> This machinery only exists within the xcode projects though and isn't used in the cmake or autotools build systems.<br>
<br>
</span>We should fix this.<br>
<span><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Managing the files and their names is pretty easy and I can handle that.<br>
><br>
> 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).<br>
<br>
</span>Why? The <a href="http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports</a> 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.<br>
<span><br>
><br>
> So:<br>
><br>
> • Is this something we want on all platforms? I think the most important of these is limiting liblldb to only exporting the public API.<br>
<br>
</span>The lldb.so should limit its exports. It makes the shared library cleaner and easier for the dynamic loaders to deal with.<br>
> • Should any other targets have their exported symbols similarly restricted? (Perhaps lldb-mi?)<br>
<br>
lldb-mi should export nothing just like argdumper and lldb-server.<br>
<br>
> • 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?<br>
<br>
I am not sure how this would work. I would rather not have something generating the <a href="http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports" rel="noreferrer" target="_blank">http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports</a> file as these files aren't too difficult to create, even if there are two copies. It currently contains:<br>
<br>
__ZN4lldb*<br>
__ZNK4lldb*<br>
_init_lld*<br>
<br>
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.<br>
<span><font color="#888888"><br>
Greg<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div>