<div class="gmail_quote">On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <span dir="ltr"><<a href="mailto:jyasskin@googlers.com" target="_blank">jyasskin@googlers.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="HOEnZb"><div class="h5">On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
> On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <<a href="mailto:dvyukov@google.com">dvyukov@google.com</a>> wrote:<br>
>><br>
>> On Tue, May 29, 2012 at 9:40 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
>> wrote:<br>
>>>>>>><br>
>>>>>>> > How do I disable that feature? I've tried -fno-builtin and/or<br>
>>>>>>> > -ffreestanding<br>
>>>>>>> > with no success.<br>
>>>>>>> clang (as well as gcc) requires that freestanding environment<br>
>>>>>>> provides<br>
>>>>>>> memcpy, memmove, memset and memcmp.<br>
>>>>>>><br>
>>>>>>> PS: Consider emailing cfedev, not llvmdev.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Hi,<br>
>>>>>><br>
>>>>>> Thanks. I've emailed cfe-dev.<br>
>>>>>> We absolutely need clang/llvm to not insert the calls into our code.<br>
>>>>><br>
>>>>><br>
>>>>> This really isn't possible.<br>
>>>>><br>
>>>>> The C++ standard essentially requires the compiler to insert calls to<br>
>>>>> memcpy for certain code patterns.<br>
>>>>><br>
>>>>> What do you really need here? Clearly you have some way of handling<br>
>>>>> when the user writes memcpy; what is different about Clang or LLVM inserting<br>
>>>>> memcpy?<br>
>>>><br>
>>>><br>
>>>> I need it for ThreadSanitizer runtime. In particular<br>
>>>><br>
>>>> <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><br>

>>>> line 1238. But I had similar problems in other places.<br>
>>>> Both memory access processing and signal handling are quite tricky, we<br>
>>>> can't allow recursion.<br>
>>><br>
>>><br>
>>> The first thing to think about is that you *do* need to use -fno-builtin<br>
>>> / -ffreestanding when compiling the runtime because it provides its own<br>
>>> implementations of memcpy.<br>
>><br>
>><br>
>> We used both at some points in time, but the problem is that they do not<br>
>> help to solve the problem. I think we use -fno-builtin now, I am not sure<br>
>> about -ffreestanding.<br>
>><br>
>>> The second is that there is no way to write fully generic C++ code w/o<br>
>>> inserting calls to memcpy. =/ If you are writing your memcpy implementation,<br>
>>> you'll have to go to great lengths to use C constructs that are guaranteed<br>
>>> to not cause this behavior, or to manually call an un-instrumented memcpy<br>
>>> implementation. I don't know of any easy ways around this.<br>
>><br>
>><br>
>> What are these magic constructs. I had problems with both struct copies<br>
>> and for loops.<br>
><br>
><br>
> Don't copy things by value ever. =/ It is really, *really* hard to do this.<br>
> If at all possible, I would build your runtime against an un-instrumented<br>
> memcpy (perhaps defined within the runtime), and then use aliases or other<br>
> techniques to wrap the instrumented functions in the exported names<br>
> necessary for use when intercepting memcpy calls from the instrumented<br>
> program.<br>
<br>
</div></div>There are some other platforms that absolutely can't tolerate function<br>
calls. Do they have an attribute or pass to tell LLVM to inline any<br>
functions it or clang inserts? Could Dmitry do the same thing?<br></blockquote><div><br></div><div>Yes, there are attributes which can be attached to the non-instrumented memcpy function, provided by the runtime and selected due to -ffreestanding, which will force inlining. __attribute__((always_inline)), __attribute__((flatten)). I suspect we don't correctly support the latter in Clang/LLVM, but that's clearly a missing feature we should fix. </div>
</div><br>