<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 31, 2012, at 6:48 PM, Chandler Carruth wrote:</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div>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.</div>
</div></blockquote><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Forming the division like this might make it easier to handle the attribution issues too enough trickery.</div><br><blockquote type="cite"><div class="gmail_quote">
<div>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....</div></div></blockquote><div><br></div>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><blockquote type="cite"><div class="gmail_quote"><div>Anyways, there seem to be a few, all somewhat bad options left to us with ASan/TSan and similar more "advanced" runtimes:</div><div><br></div><div>1) Swallow the lame binary attribution clause requirement. Document this noisily.</div>
<div>2) Require they are build as DSOs, and thus the attribution restricted to that runtime library entity.</div></div></blockquote><div><br></div><div>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?</div><br><blockquote type="cite"><div class="gmail_quote"><div>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.</div>
<div>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.</div></div></blockquote><div><br></div><div>#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.</div><br><blockquote type="cite"><div class="gmail_quote">
<div>#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.</div></div></blockquote><div><br></div><div>Yeah.</div><br><blockquote type="cite"><div class="gmail_quote">
<div>#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).</div>
</div>
</blockquote></div><br><div>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.</div><div><br></div><div>-Chris</div></body></html>