<div dir="ltr">Thanks for pointing this out, Tim. Then maybe this approach is not the best choice for x86, though ideally measuring is needed, it is just that on ARM the current x86 approach is not applicable because ARM doesn't have a single return instruction (such as RETQ on x86_64), furthermore, the return instructions on ARM can be conditional.<div><br></div><div>I have another question: what happens if the instrumented function (or its callees) throws an exception and doesn't catch? I understood that currently XRay will not report an exit from this function in such case because the function doesn't return with RETQ, but rather the stack unwinder jumps through functions calling the destructors of local variable objects.</div><div><br></div><div>If so, why not to instrument the functions by placing a tracing object as the first local variable, with its constructor calling __xray_FunctionEntry and destructor calling __xray_FunctionExit ? Perhaps this approach requires changes in the front-end (C++ compiler, before emitting IR).</div><div><br></div><div>Cheers.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 July 2016 at 21:00, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 28 July 2016 at 16:14, Serge Rogatch via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Can I ask you why you chose to patch both function entrances and exits,<br>
> rather than just patching the entrances and (in the patches) pushing on the<br>
> stack the address of __xray_FunctionExit , so that the user function returns<br>
> normally (with RETQ or POP RIP or whatever else instruction) rather than<br>
> jumping into __xray_FunctionExit?<br>
<br>
</span><span class="">> This approach should also be faster because smaller code better fits in CPU<br>
> cache, and patching itself should run faster (because there is less code to<br>
> modify).<br>
<br>
</span>It may well be slower. Larger CPUs tend to track the call stack in<br>
hardware and returning to an address pushed manually is an inevitable<br>
branch mispredict in those cases.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>