[LLVMdev] How to prevent insertion of memcpy()

[Dmitry Vyukov]

On Tue, May 29, 2012 at 9:50 PM, Chandler Carruth <chandlerc at google.com>wrote:

> > How do I disable that feature? I've tried -fno-builtin and/or
>>>>>>> -ffreestanding
>>>>>>> > with no success.
>>>>>>> clang (as well as gcc) requires that freestanding environment
>>>>>>> provides
>>>>>>> memcpy, memmove, memset and memcmp.
>>>>>>>
>>>>>>> PS: Consider emailing cfedev, not llvmdev.
>>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks. I've emailed cfe-dev.
>>>>>> We absolutely need clang/llvm to not insert the calls into our code.
>>>>>>
>>>>>
>>>>> This really isn't possible.
>>>>>
>>>>> The C++ standard essentially requires the compiler to insert calls to
>>>>> memcpy for certain code patterns.
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> I need it for ThreadSanitizer runtime. In particular
>>>>
>>>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interceptors.cc?view=annotate
>>>> line 1238. But I had similar problems in other places.
>>>> Both memory access processing and signal handling are quite tricky, we
>>>> can't allow recursion.
>>>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>> 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.
>>>
>>
>> What are these magic constructs. I had problems with both struct copies
>> and for loops.
>>
>
> Don't copy things by value ever. =/ It is really, *really* hard to do this.
>

Do you mean 'don't do struct copies'? Are there other problems aside from
implicit memcpy calls?


> 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.
>

I am not sure I understand it.
We can't afford function calls scattered at random places. It will cost 30%
of performance of so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120529/7ec12b14/attachment.html>