[LLVMdev] How to prevent insertion of memcpy()

Chandler Carruth chandlerc at google.com
Tue May 29 10:40:04 PDT 2012


On Tue, May 29, 2012 at 10:28 AM, Dmitry Vyukov <dvyukov at google.com> wrote:

> On Tue, May 29, 2012 at 9:16 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120529/a83b5c5b/attachment.html>


More information about the llvm-dev mailing list