<br><br><div class="gmail_quote">On Fri, Jun 1, 2012 at 12:56 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Fri, Jun 1, 2012 at 12:49 PM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@googlemail.com" target="_blank">benny.kra@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
On 01.06.2012, at 08:14, Kostya Serebryany wrote:<br>
<br>
><br>
><br>
> On Fri, Jun 1, 2012 at 7:13 AM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br>
> On May 31, 2012, at 6:48 PM, Chandler Carruth wrote:<br>
>> I'm not sure that this solves the problem. The reason we have dual licenses for the runtime stuff is that we don't want the UIUC license (which has a binary attribution clause) to affect stuff built with the compiler. Saying that "clang -fasan produces code that has to binary attribute the LLVM license" is pretty lame.<br>
>><br>
>> I think that what is *traditionally* thought of as compiler-rt has different needs from ASan/TSan/etc. The latter runtimes are really intended to be separate units from the binary; for example none of their code would ever be directly emitted into a function, etc. Certainly the scope and complexity of them are very different, and so it might still make sense to split these into two groups of runtime libraries.<br>
><br>
> To be clear, compiler-rt isn't injected into functions. Maybe a better definition is that compiler-rt is statically linked in, vs the more advanced runtimes that are dynamically linked in.<br>
><br>
> Forming the division like this might make it easier to handle the attribution issues too enough trickery.<br>
><br>
>> Were I drawing an arbitrary line, I would draw it around the runtime libraries which are stand-alone and implement an available spec for which other implementations can and do exist. (libgcc, libstdc++, etc etc.) Regardless of licensing issues, I suspect making this bucketing more clear would simplify some of these projects....<br>
><br>
> Yeah, I completely agree with your goals. This is one of the big concerns I had back when the dual licensing happened in the first place.<br>
><br>
><br>
>> Anyways, there seem to be a few, all somewhat bad options left to us with ASan/TSan and similar more "advanced" runtimes:<br>
>><br>
>> 1) Swallow the lame binary attribution clause requirement. Document this noisily.<br>
>> 2) Require they are build as DSOs, and thus the attribution restricted to that runtime library entity.<br>
><br>
> Maybe 2a: engineer asan so that it *optionally* links to the DSO. If the DSO is present, functionality is enabled, if not, it is silently disabled and the app still works (at some performance cost). Could this work?<br>
><br>
> DSO? You mean to make asan.so instead of asan.a?<br>
> This will work, but may cause confusion. If asan.so is not present, the asan-ified binary will crash instantly.<br>
><br>
> For tsan, making it tsan.so instead of tsan.a will cause a huge performance penalty because tsan reads TLS on every memory access.<br>
<br>
</div>It depends where you need to use LLVM libraries. Going back to the initial post of this thread, LLVM libraries will be used by asan/tsan to symbolicate stack traces. If that's the only use of LLVM in asan it would make a lot of sense to split that part into a DSO and link it on demand. </blockquote>
<div><br></div></div><div>That'll work too and is indeed simpler. </div></div></blockquote><div><br></div><div>Yes. Is there an easy way to build that part of LLVM (Support and DebugInfo) as .so files as well as .a?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div>--kcc </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That way we don't have to link all the (large) debug info code into every binary built with asan and have a nice workaround for the licensing issue.<br>
<br>
I'm mildly opposed to relicensing parts of LLVM. While it makes sense to have lib/Support as liberally licensed as possible I'm afraid that it will creep into other parts too. Asking all developers to agree to a license change and reimplementing stuff written by people who won't answer is feasible but it will be painful and, in my opinion, a waste of development resources that are better spent improving LLVM.<br>
<br>
- Ben<br>
<div><div><br>
><br>
> --kcc<br>
><br>
><br>
><br>
>> 3) Build the functionality needed by ASan/TSan/etc independently of LLVM's core libraries. Code duplication here, and only a dim hope that we could package in a way that lldb or others might be able to shift to depend upon the dual-licensed functionality rather than the core LLVM functionality.<br>
>> 4) Start moving core LLVM libraries into a separate 'core library' or 'common library' project which has the dual-license requirement, but is a "lower-level" component than LLVM itself.<br>
><br>
> #4 is somewhat independently useful anyway. The support and system libraries are the lowest level (from a layering perspective) and most reusable across sub-projects. Actually relicensing them would be a major effort though.<br>
><br>
>> #3 seems like painting ourselves into a corner, and borrowing a lot of technical debt in the future. I suspect we'll keep having to replicate functionality here.<br>
><br>
> Yeah.<br>
><br>
>> #4 is interesting, but a *ton* of work. The Object library, most of Support and System, all would have to sink into this core module, all would have to get dual-licensed (ow!!! how? some of the contributors are around to agree to new license, but not all... likely a fair amount of rewrite required to produce new versions of libraries under the correct license).<br>
><br>
> I think that #4 is the best long term answer, but yeah... oww. If you're interested in stack traces in particular, making pieces "optionally enabled" seems really attractive.<br>
><br>
> -Chris<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</div></div></blockquote></div></div><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div><br>