<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">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 class="im">
<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>OK</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 class="im"><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 class="im">
<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>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><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 class="im"><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>Is it the case for C++ library that llvm uses?</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>
I suspect that C/C++ library can use them.</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>The linker does not understand them.</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><br><div>Well, most likely yes.</div><div><br></div><div>There may be additional limitations that I don't know yet.</div><div><br></div></font></div>