<div class="gmail_quote">On Thu, Jun 28, 2012 at 11:56 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is a small problem. I declare the functions inside the runtime as:<div><div>extern "C" inline void *__attribute__((always_inline, __nothrow__)) memcpy(void *dst, const void *src, uptr size) {</div><div> ...</div>
<div>}</div><div>They are inlined into runtime, that's OK. But they are also compiled into runtime library and supersede our interceptors. So that when user code calls memcpy, it calls this non-instrumented function. That's not OK.</div>
<div>Any suggestions?</div><div>FWIW, tomorrow I am going to try to add __asm__("__fake_memcpy__") :)</div></div></blockquote><div><br></div><div><br></div><div>I see why it happens. We take address of memcpy in some places, and so compiler decides to generate the function. (The address is intended to be an address of the "other" memcpy).</div>
<div>I finally get it working state. But it become extremely messy with significant amount of changes all over the place.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 28, 2012 at 1:12 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div>On Thu, Jun 28, 2012 at 2:09 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It specifically prevents replacing your implementation of memcpy with a call to memcpy, resulting in an infloop. This will actually happen in some cases.</blockquote><div><br></div></div><div>Why can't the same happen with a hosted impl?</div>
<div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I personally think we should also provide a way to avoid the introduction of *any* calls to memcpy, and instead synthesize the loops directly. That said, while we are close to that today, there are still a few places that will do this.</div>
</blockquote><div><br></div></div><div>It would be nice. For some reason I still have a feeling that I am fighting against implementation details of the particular compiler.</div><div><div><div><br></div><div>
<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 27, 2012 at 3:04 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div>On Thu, Jun 28, 2012 at 1:56 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unless you specify -fno-builtin, the compiler (even the low-level code generator) is free to insert a call to 'memcpy', assuming that a libc will eventually show up and provide that function. It may not be happening yet, but it will be eventually.<div>
<br></div><div>No amount of always-inline annotations help this, because the calls may get inserted after inlining has taken place.</div></blockquote><div><br></div><div><br></div></div><div>Since freestanding implementations provide memcpy, how can -ffreestanding/-fno-builtin help with this?... Why a compiler is disallows to insert memcpy's in this case?</div>
<div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">
On Wed, Jun 27, 2012 at 2:44 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br><div class="gmail_extra">On Thu, Jun 28, 2012 at 1:32 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div>On Wed, Jun 27, 2012 at 2:16 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div>On Thu, Jun 28, 2012 at 1:07 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect you'll need to work still harder than this... =[</blockquote><div><br></div></div><div>I know :)</div><div>Now I need to understand how exactly it is broken.</div></div></div></blockquote><div><br></div></div>
<div>
Hmm, I may also need to better understand what you're attempting to achieve with this patch (based on Timur's comment).</div><div><br></div><div>You define memset, memcpy, etc in a header file -- what callers use them? Most callers moved to 'internal_foo' versions.</div>
<div><br></div><div>To answer Timur's question -- yes its ok, but it's hard to control which (instrumented or not-instrumented) gets used if they are inserted by LLVM, and thus have the normal names. It occurs to me that my post-process name-mangling tool would solve this problem as well...</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>You'll need to compile with -fno-builtins in order to prevent LLVM's optimizer from recognizing your code as equivalent to 'memset' or 'memcpy', and replacing it with a call to those functions. =/</div>
</blockquote><div><br></div></div><div>I believe we are compiling with -fno-builtin.</div><div>You mentioned that I also need <span style="font-family:arial,sans-serif;font-size:12.800000190734863px">-ffreestanding:</span></div>
</div></div></blockquote><div><br></div></div><div>Yea, -ffreestanding may be better. It is a superset of -fno-builtin</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote">
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">"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))</span><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">, __attribute__((flatten))"</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Why do I need it?</span></div></div></div>
</blockquote><div><br></div></div><div>Need which?</div><div><br></div><div>You need '-ffreestanding' so that your source code can implement 'memset' itself, and that implementation will be used rather than assuming that at some point 'libc' will get linked in and we can call *its* memset. This is necessary even if your function isn't named 'memset' but something eles.</div>
<div><br></div><div>The __attribute__((always_inline)) is needed if you want to force this function to be inlined into its callers. I don't recall off hand why this was important?</div></div></div>
</blockquote></div><br></div><div class="gmail_extra"><br></div></div></div><div class="gmail_extra">I need to prevent compiler from inserting memxxx() calls into random places of the runtime. At first glance the patch achieves the goal.</div>
<div class="gmail_extra">always_inline is required to eliminate calls.<br></div><div class="gmail_extra">I do not fully understand why <span style="color:rgb(80,0,80)"> </span><span style="color:rgb(80,0,80)">-fno-builtins/</span>-ffreestanding are required. The idea is that the compiler leaves no calls to memxxx (everything is inlined).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br>