<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>
<div><br></div><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><div>
<br></div><div>Soon I will start integrating tsan into Go language. For the Go language we need very simple object files. No global ctors, no thread-local storage, no weak symbols and other trickery. Basically what a portable C compiler could have produced.</div>
<div><br></div><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 10:05 AM, 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><div class="h5"><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><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><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 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">Hello folks (and sorry if I've forgotten to CC anyone with particular interest to this discussion...):<div>
<br></div><div>I've been thinking a lot about how best to build advanced runtime libraries like ASan, and scale them up. Note that this does *not* try to address any licensing issues. For now, I'll consider those orthogonal / solvable w/o technical contortions. =]</div>
<div><br></div><div>My primary motivation: we really, *really* need runtime libraries to be able to use common, shared libraries.</div></font></div></blockquote><div><br></div></div><div>I am not sure you understand the problem as we do. </div>
<div><br></div><div>In short, asan/tsan/msan/etc can not use any function which is also called from the instrumented binary.</div></div></font></div></blockquote><div><br></div></div><div>Well, I can't be sure, but this description certainly agrees with my understanding -- you need *every* part of the runtime to be completely separate from *every* part of the instrumented binary. I'm with you there.</div>
<div><br></div><div>In particular, I think the current strategy for libc & system calls makes perfect sense, and I'm not trying to suggest changing it.</div><div><br></div><div>I think the most similar situation is is this one:</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 class="gmail_quote"><div>In the previous version of ThreadSanitizer we used a private copy of STLport in a separate namespace and a custom libc (small subset).</div>
</div></font></div></blockquote><div><br></div></div><div>My proposal is very similar except without the need to modify the C++ standard library in use. Instead, I'm suggesting post-processing the library to ensure that the standard C++ library code in the runtime is kept complete distinct from that in the instrumented binary -- everything would in fact be *mangled* differently.</div>
<div><br></div><div>The goal would be to avoid the maintenance overhead of a custom C++ standard library, and instead use a normal one. My understanding is that both GCC's libstdc++ and LLVM's libc++ are significantly higher quality than STLport, and if we're doing static linking, the code bloat should be greatly reduced. We could reduce it still further by doing LTO of the runtime library, which should be very straight forward given the rest of my proposal.</div>
<div><br></div><div>It would still require a very small subset of libc, likely not much more than you already have.</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 class="gmail_quote"><div> This worked, but had problems too (Dmitry was very angry at STLport for code bloat, stack size increase and some direct libc calls).</div>
</div></font></div></blockquote><div><br></div></div><div>I would be interested to know if the above addresses most of the problems or not.</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>Until recently this was not causing too much pain in asan/tsan, but our attempts to use the LLVM DWARF readers made it worse.</div><div>When tsan finds a race, we need to symbolize it online to be able to match against a suppression and decide whether we want to emit the warning. Today we do it in a separate addr2line process (ugly and slow). </div>
<div>But if we start calling the LLVM dwarf reader we end up with all possible dependency problems (Dmitry and Alexey will know the exact ones) because the LLVM code calls to malloc, memcpy, etc. </div><div><br></div><div>
Frankly, I don't have any solution other than to change the code such that it does not call libc/libc++.</div><div>Some of that may be solved by a private copy of STLport + a bit of custom libc (but see above about STLport)</div>
</div></font></div></blockquote><div><br></div></div><div>I think my proposal is essentially in between these two:</div><div><br></div><div>- Avoid the need for a low quality STL by using a normal C++ standard library implementation, and avoid maintenance burden by doing a link-time mangling of the symbols.</div>
</div></font></div></blockquote><div><br></div></div></div><div>re-linking might be too platform specific. </div><div>How about compiling the library into LLVM bitcode and adding namespaces/prefixes to that bitcode? </div>
</div></font></div></blockquote><div><br></div></div></div><div>Re-linking is a bit platform specific...</div><div><br></div><div>It would definitely work on ELF platforms, and likely on Darwin, but Windows is tricky.</div>
<div><br></div>
<div>On windows we would at least need a custom tool, but such a tool would be quite easy to write I suspect. We could even use the very LLVM libraries in question to write it! ;] Amusingly, I think with the LLVM libraries we could very easily write a custom tool just to mangle the symbol names in a collection of object files very easily and have it work on *most* platforms!</div>
<div><br></div><div>Still, the bitcode idea is interesting. Doing this entirely in bitcode has some advantages as these types of runtimes are among the best uses for things like LTO: they're small, performance sensitive, can enumerate the entry points easily, and are likely to have a particular need for dead code elimination.</div>
</div></font></div></blockquote><div><br></div></div></div><div>One reason to want to have some support for doing this w/o bitcode: we may not have the bitcode. Specifically, the goal would be to use the "normal" C++ standard library, provided it is available to link statically (libstdc++ and libc++ certainly are, I don't know about MSVC). That would be much easier if we can actually use the existing archive file, and just "fix" the .o files inside it.</div>
<div><br></div><div>It seems likely to be the equivalent of an 'ld -r' run with a linker script to munge the symbol names, or potentially a custom tool written with the LLVM object file libraries.</div></div></font></div>
</blockquote></div><br></font></div>