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