[LLVMdev] How to prevent insertion of memcpy()

[Chandler Carruth]

On Tue, May 29, 2012 at 11:11 AM, Jeffrey Yasskin <jyasskin at googlers.com>wrote:

> On Tue, May 29, 2012 at 10:50 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > On Tue, May 29, 2012 at 10:46 AM, Dmitry Vyukov <dvyukov at google.com>
> wrote:
> >>
> >> 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.
> >
> >
> > Don't copy things by value ever. =/ It is really, *really* hard to do
> this.
> > 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.
>
> There are some other platforms that absolutely can't tolerate function
> calls. Do they have an attribute or pass to tell LLVM to inline any
> functions it or clang inserts? Could Dmitry do the same thing?
>

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