[LLVMdev] How to prevent insertion of memcpy()

[Dmitry Vyukov]

On Tue, May 29, 2012 at 9:40 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120529/249deeff/attachment.html>