On Thu, Aug 2, 2012 at 10:59 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank" class="cremed">samsonov@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi, llvm-commits</div><div><br></div><div>Here: <a href="http://codereview.appspot.com/6458066/" target="_blank" class="cremed">http://codereview.appspot.com/6458066/</a> is the short experimental FYI-patch that allows LLVM sources to be "compiled into" static compiler-rt libraries in CMake build system.</div>

<div>(I'm not sure that is smart enough to capture all dependencies, though).</div><div>With something that simple we can:</div><div>1) directly use LLVM code from compiler-rt libraries.</div><div>2) workaround the unavailable compilation of llvm libraries for several targets: each static compiler-rt lib will contain its own private copy of LLVM libs, compiled for necessary target and with necessary compile flags.</div>
</blockquote><div><br></div><div>I've not looked at the patch yet, but some initial points... I'm a bit sad to start *another* thread, much of this was discussed in my RFC thread from some time ago, but here is a re-cap:</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And there are multiple drawbacks:</div><div>1) License issues (LLVM code has binary redistribution clause, right? So everything built with "clang -faddress-sanitizer" would attribute LLVM license, gr-r-r).</div>
</blockquote><div><br></div><div>We are looking into fixing this, I'm fairly confident that in one form or another, this will largely be a temporary issue. Let's not discuss that to death here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>2) Static ASan runtime is now 10x larger (2,5M vs 250K), while most of its functionality (various stuff from LLVMSupport) is not needed.</div></blockquote><div><br></div><div>This is simply poor structuring of the library, or misbehavior by the linker. We should figure out what's causing it and fix this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>3) Symbol name clashes - suppose one want to build something with ASan and link against "normal" version of LLVMSupport. (can compiling the code with -fvisibility=hidden, as we currently do, help with this?)</div>
</blockquote><div><br></div><div>-fvisibility=hidden won't help at all.</div><div><br></div><div>This is what my RFC was about, specifically solving this problem. Perhaps we should actually go that route? ;] It keeps coming up, and there is a fairly direct solution that is a "small matter of code" to achieve.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Does this direction look promising to you?</div></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Maybe, we should turn to using DSO instead?</div>
</blockquote><div><br></div><div>We could in theory, but I was under the distinct impression that DSO-s were a non-starter for several different reasons:</div><div><br></div><div>1) Introduces complex rpath requirements into binaries, making distribution even harder.</div>
<div>2) Introduces small performance overhead into the runtime library in all cases... Maybe we could live with this though.</div><div>3) Introduces dramatic performance overhead into TLS for the runtime library, a likely deal-breaker for tsan.</div>
<div><br></div><div>To elaborate on #1 a bit, I'm not very enthusiastic about a strategy that *precludes* a statically linked binary from using the full runtime library. It also will limit the reach of asan on platforms which don't have a good DSO story or where it would be infeasible to get the DSO in place.... We have very real world use cases that fall into this category.</div>
<div><br></div><div><br></div><div>The drawbacks of the DSO approach seem fundamental to the technology used. The drawbacks to the static library seem like solvable technical challenges we need to write some code to deal with.</div>
</div></div>