<div class="gmail_quote">On Tue, May 29, 2012 at 9:50 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 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 class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> How do I disable that feature? I've tried -fno-builtin and/or -ffreestanding<br>
> with no success.<br>
</div>clang (as well as gcc) requires that freestanding environment provides<br>
memcpy, memmove, memset and memcmp.<br>
<br>
PS: Consider emailing cfedev, not llvmdev.<br></blockquote><div><br></div></div><div>Hi,</div><div><br></div><div>Thanks. I've emailed cfe-dev.</div><div>We absolutely need clang/llvm to not insert the calls into our code.</div>





</div></blockquote><div><br></div></div></div><div>This really isn't possible.</div><div><br></div><div>The C++ standard essentially requires the compiler to insert calls to memcpy for certain code patterns.</div><div>




<br></div><div>
What do you really need here? Clearly you have some way of handling when the user writes memcpy; what is different about Clang or LLVM inserting memcpy? </div></div>
</blockquote></div><br></div><div>I need it for ThreadSanitizer runtime. In particular</div><div><a href="http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interceptors.cc?view=annotate" target="_blank">http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interceptors.cc?view=annotate</a></div>




line 1238. But I had similar problems in other places.<div><div>Both memory access processing and signal handling are quite tricky, we can't allow recursion.</div></div></blockquote><div><br></div></div></div><div>The first thing to think about is that you *do* need to use -fno-builtin / -ffreestanding when compiling the runtime because it provides its own implementations of memcpy.</div>


</div></blockquote><div><br></div></div><div>We used both at some points in time, but the problem is that they do not help to solve the problem. I think we use -fno-builtin now, I am not sure about -ffreestanding.</div><div>

<div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>The second is that there is no way to write fully generic C++ code w/o inserting calls to memcpy. =/ If you are writing your memcpy implementation, you'll have to go to great lengths to use C constructs that are guaranteed to not cause this behavior, or to manually call an un-instrumented memcpy implementation. I don't know of any easy ways around this. </div>



</div>
</blockquote></div></div><br><div>What are these magic constructs. I had problems with both struct copies and for loops.</div></blockquote><div><br></div></div></div><div>Don't copy things by value ever. =/ It is really, *really* hard to do this.</div>
</div></blockquote><div><br></div><div>Do you mean 'don't do struct copies'? Are there other problems aside from implicit memcpy calls?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div> If at all possible, I would build your runtime against an un-instrumented memcpy (perhaps defined within the runtime), and then use aliases or other techniques to wrap the instrumented functions in the exported names necessary for use when intercepting memcpy calls from the instrumented program.</div>

</div>
</blockquote></div><br><div>I am not sure I understand it.</div><div>We can't afford function calls scattered at random places. It will cost 30% of performance of so.</div><div><br></div>