<p dir="ltr">Valgrind is still going to be single threaded, right?</p>
<div class="gmail_quote">25 февр. 2014 г. 22:10 пользователь "Denis Steckelmacher" <<a href="mailto:steckdenis@yahoo.fr">steckdenis@yahoo.fr</a>> написал:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/25/2014 04:50 PM, John Criswell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think a more interesting idea would be to use LLVM to perform<br>
instrumentation and then to use Valgrind to instrument third-party<br>
libraries linked into the program.<br>
<br>
What I'm imagining is this: Let's say you instrument a program with<br>
SAFECode or Asan to find memory safety errors.  When you run the program<br>
under Valgrind, the portion of the code instrumented by SAFECode or Asan<br>
runs natively without dynamic binary instrumentation because it's<br>
already been instrumented.  When the program calls uninstrumented code<br>
(e.g., code in a dynamic library), Valgrind starts dynamic binary<br>
instrumentation to do instrumentation.<br>
<br>
A really neat thing you could do with this is to share run-time data<br>
structures between the LLVM and Valgrind instrumentation.  For example,<br>
Valgrind could use SAFECode's meta-data on object allocations and<br>
vice-versa.<br>
<br>
</blockquote>
<br>
Someone proposed to cache the results of a JIT compilation. Caching LLVM bitcode is easy (and the LLVM optimizations operate on bitcode, so they don't need to be re-run on bitcode reload), and may be a good way to fasten Valgrind. Caching native binary code is more difficult and would only be useful if LLVM's codegen is slow (I think that the codegen can be configured to be fast, for instance by using a simpler register allocator).<br>

<br>
If every .so is cached in a separate bitcode file, loading an application would only require the generation of bitcode for the application itself, not the libraries it uses, provided that they didn't change since another application using them was analyzed. That may speed up the start-up of Valgrind.<br>

______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div>