Reviving the discussion.<div><br></div><div>The cool cmake-build of compiler-rt is not completely functional, but allows sanitizer runtimes to reuse LLVM code with almost no dirty hacks.</div><div>Suppose I want to run call functions from LLVM libs (currently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime.<div>
<br></div><div>1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime perfectly (wow).</div><div>2) Now building and running ASan unittests is simple - you just have to add a couple of lines to CMakeLists.</div>
<div><div> target_link_libraries(${testname} LLVMSupport)</div><div> target_link_libraries(${testname} LLVMDebugInfo)</div></div><div>3) Now to make "-faddress-sanitizier" work you have to patch a Clang driver, so that it links not only ASan runtime, but also two</div>
<div> of the mentioned static LLVM libraries (and add -lstdc++ flag as well).</div><div><br></div><div>But, as Dmitry mentioned, we may run into troubles as we may mix instrumented and un-instrumented</div><div>versions of the same functions (identical methods from std::vector<> will be instrumented in user-code and not instrumented in LLVM code).</div>
<div>This problem seem to be more important for TSan (it takes some effort to check that, as TSan is not currently buildable with LLVM, I think</div><div>I can try to fix this soon).</div><div><br></div><div>Chandler, is this exactly the problem you're trying to solve with your linker tool?</div>
<div>Dmitry, do I understand correctly that it's really better to get rid of unnecessary (if not all) STL in LLVM methods we plan to use anyway?</div><div><div><div><br><div class="gmail_quote">On Thu, Jun 21, 2012 at 2:06 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif"><font><div><div class="h5"><div class="gmail_quote">On Thu, Jun 21, 2012 at 1:44 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif">
<font><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote">
<div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif">
<font><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif"><font>Can we alter the build system so that when building a run-time library it modifies all .cpp files like this:<div>
namespace FOO {</div><div> <file body></div>
<div> }</div><div>This will give us essentially the same thing, but w/o system dependent object file hackery. </div><div>Maybe we can add a Clang flag to add such a namespace for us? </div></font></div></blockquote><div>
<br></div></div><div>I think this is essentially what Dmitry was talking about w/ past STLport experience. It has lots of limitations:</div></div></font></div></blockquote><div><br></div></div><div>Patching object files still sounds much scarier and harder to port. </div>
<div>I'd prefer to find a solution that involves only source files and maybe clang.</div><div>Pondering...</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div><br></div><div>- You can't use the normal system standard library</div></div></font></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:arial,helvetica,sans-serif"><font><div class="gmail_quote"><div>- You have to build the standard library from source</div>
<div>- You can't wrap certain parts of it (operator new, delete, a few other things)</div><div>- You can't re-use any C libraries (zlib for example)</div></div></font></div></blockquote></div></div></font></div></blockquote>
<div><br></div><div><br></div></div></div><div>Perhaps you are solving a broader problem. But as for asan/tsan, we currently need only symbolizer, it's separable from everything else, and can be made to not use STL.</div>
</div></font></div></blockquote><div><br></div></div></div><div>If you want to share LLVM code for the object and dwarf reading, I do not believe this to be true at all. </div></div></font></div>
</blockquote></div><br></div><div>I've already removed code for the object reading for exactly that reason, so now it's just dwarf parsing :) There are some CTL containers involved, but I think they can be replaced.</div>
</font></div></blockquote><div><br></div></div></div><div>Agree here. I hope to modify/extend this code soon anyway.</div></div></font></div></blockquote><div><br></div></div></div><div>Folks, this is not the path to sharing code. This is the path to forking code.</div>
<div><br></div><div>Let's go back to the very premise: I think it is highly desirable to be capable of building runtimes such as ASan and TSan and *share* code rather than forking it.</div><div><br></div><div>I have reasons: I have seen the creation of at least three separate ELF and/or DWARF parsing libraries thus far. I have seen a long series of bugs found and fixed in them over the course of years, often the same bug, often with great expense in debugging to understand why. I don't want us to keep paying this cost. I don't think these pieces of code are likely to be alone in this.</div>
<div><br></div><div><br></div><div>Now, perhaps I am wrong, and it is not worth it. Thus far, I don't hear any convincing arguments to that effect, but I'm very willing to believe I'm wrong as I don't work on one of these runtimes, and so don't have a direct appreciation for all of the costs involved.</div>
<div><br></div><div>But let's be extremely clear on what you are suggesting: you are specifically doing away with the very idea of sharing code with the rest of the LLVM project, and instead deciding to fork and write custom code in the runtime for all functionality.</div>
</div></font></div>
</blockquote></div><br><div><br></div></div></div><div>No, we do not want to fork any code. </div><div>My ObjectFile replacement is 20 lines of code including error handling (open file, get size, mmap).</div><div><br></div>
</font></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div><br>
</div></div></div></div>