<div style="font-family: arial, helvetica, sans-serif"><font size="2">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><div>(This approach, as well as Chandler's original approach will have to deal with malloc, memset, strlen, etc which still need to reside in the global namespace)</div>
<div><br></div><div>--kcc </div><div><br><br><div class="gmail_quote">On Thu, Jun 21, 2012 at 12:10 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 size="2"><div class="gmail_quote"><div class="im">On Thu, Jun 21, 2012 at 1:04 AM, 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 size="2"><div class="gmail_quote"><div>On Thu, Jun 21, 2012 at 11:52 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<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 size="2"><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 size="2"><div>Hi,</div><div><br></div><div>Yes, stlport was a pain to deploy and maintain + it calls normal operator new/delete (there is no way to put them into a separate namespace).</div>
</font></div></blockquote><div><br></div></div><div>Ok, but putting the raw symbols into a "namespace" with the linker shouldn't be subject to these limitations.</div></div></font></div></blockquote><div><br>
</div></div><div>OK</div><div><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 size="2"><div class="gmail_quote">
<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 size="2">
<div>Note that in some codebases we build asan/tsan runtimes from source. How the build process will look with that object file mangling? How easy it is to integrate it into a custom build process?</div></font></div></blockquote>
<div><br></div></div><div>Well, I don't know yet. ;] It was an idea, I don't have an implementation at this point. That said, I had only really imagined building the runtimes from source? Maybe I don't understand what you mean by this?</div>
<div><br></div><div>The vague strategy I am imagining for the build proces is this:</div><div><br></div><div>1) compile runtime into a static library, just like any other static library</div><div><br></div><div>2) collect all the '.o' files in the static archive, and in any dependencies' static archive libraries</div>
<div><br></div><div>3) for each 'foo.o' build a 'foo_munged.o' using $tool, the _munged version has all symbols not on the whitelist for export to the instrumented binary</div><div><br></div><div>4) put all of the _munged '.o' files into a single runtime archive</div>
<div><br></div><div><br></div><div>The $tool here could be "ld -r" with a linker script, or (likely necessary on windows) a very simple, dedicated tool built around the LLVM object libraries to copy each symbol, munging the name.</div>
<div>
<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 size="2"><div>Soon I will start integrating tsan into Go language. For the Go language we need very simple object files.</div>
</font></div></blockquote><div><br></div></div><div>Ok... I'm not sure whether this should really constrain the way we build the core runtime system here though. If you need some logic on the tsan side factored out into a separate library for use with Go, that would seem simpler than trying to make one sanitizer runtime library to support frontends, middle ends, and programming languages with totally separate models.</div>
</div></font></div></blockquote><div><br></div></div><div>Yes, it will be a separate runtime library. But if tsan sources are deeply dependent on llvm sources, this may be significantly harder to do.</div></div></font></div>
</blockquote><div><br></div></div><div>I think we should cross this bridge when we get there.</div><div><br></div><div>When we do, I suspect it will be reasonable, in a worst case situation, to abstract the business logic into an isolated shared component. My hope is that we won't even need to...</div>
<div class="im">
<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 size="2"><div class="gmail_quote"><div>
<div><br></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 size="2"><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 size="2"><div> No global ctors, no thread-local storage, no weak symbols and other trickery. Basically what a portable C compiler could have produced.</div>
</font></div></blockquote><div><br></div></div><div>These also don't seem insurmountable, even in the existing use cases. But maybe I'm not considering the actual restrictions you are, or I've misunderstood. Here is how I'm breaking down the things you've mentioned:</div>
</div></font></div></blockquote><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 size="2"><div class="gmail_quote">
<div><br></div><div>1) It seems reasonable to avoid global constructors, and do-able in C++ even when using the standard library and parts of LLVM. LLVM itself specifically works to avoid them.</div></div></font></div></blockquote>
<div><br></div></div><div>Is it the case for C++ library that llvm uses?</div></div></font></div></blockquote><div><br></div></div><div>LLVM is extremely resistent to growing external dependencies specifically because it cannot control them. In particular the parts that a runtime is likely to use are very unlikely to grow any problematic dependencies here. Essentially, it is reasonable to assert that we have control over all of LLVM's dependencies and can arrange for them to be very conservative here.</div>
<div class="im">
<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 size="2"><div class="gmail_quote"><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 size="2"><div class="gmail_quote"><div>2) TLS doesn't seem to be required by anything I'm suggesting... is there something that worries you about this?</div></div></font></div></blockquote><div><br></div></div>
<div>
I suspect that C/C++ library can use them.</div></div></font></div></blockquote><div><br></div></div><div>I would be very surprised if these parts of LLVM use them. If they did, I think it would be reasonable to make it optional and disable it in some circumstances.</div>
<div class="im">
<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 size="2"><div class="gmail_quote"><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 size="2"><div class="gmail_quote">
<div>3) I don't understand the requirement to have no weak symbols. Even a portable C compiler might produce weak symbols?</div></div></font></div></blockquote><div><br></div></div><div>The linker does not understand them.</div>
<div>
<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 size="2"><div class="gmail_quote"><div>Still, during the re-linking phase above, it should be possible to resolve any weak symbols?</div>
</div></font></div>
</blockquote></div></div><br><div>Well, most likely yes.</div><div><br></div><div>There may be additional limitations that I don't know yet.</div></font></div>
</blockquote></div></div><br><div>Sure, time will tell. That said, I don't think future work to support Go should be the top priority in getting this system well integrated, and I don't think there are any huge road blocks already clear at this stage related to Go.</div>
</font></div>
</blockquote></div><br></div></font></div>