search for: __xray_functionexit

Hello, Can I ask you why you chose to patch both function entrances and exits, rather than just patching the entrances and (in the patches) pushing on the stack the address of __xray_FunctionExit , so that the user function returns normally (with RETQ or POP RIP or whatever else instruction) rather than jumping into __xray_FunctionExit? By patching just the function entrances, you avoid duplication of the function ID (which is currently taking space in the entrance and every exit) and dupl...

> On 29 Jul 2016, at 09:14, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > Can I ask you why you chose to patch both function entrances and exits, rather than just patching the entrances and (in the patches) pushing on the stack the address of __xray_FunctionExit , so that the user function returns normally (with RETQ or POP RIP or whatever else instruction) rather than jumping into __xray_FunctionExit? > > By patching just the function entrances, you avoid duplication of the function ID (which is currently taking space in the entrance and every exit...

...erge Rogatch via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hello, > > > > Can I ask you why you chose to patch both function entrances and exits, > rather than just patching the entrances and (in the patches) pushing on the > stack the address of __xray_FunctionExit , so that the user function > returns normally (with RETQ or POP RIP or whatever else instruction) rather > than jumping into __xray_FunctionExit? > > > > By patching just the function entrances, you avoid duplication of the > function ID (which is currently taking space in the...

...;t return with RETQ, but rather the stack unwinder jumps through functions calling the destructors of local variable objects. 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). Cheers. On 29 July 2016 at 21:00, Tim Northover <t.p.northover at gmail.com> wrote: > On 28 July 2016 at 16:14, Serge Rogatch via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > &g...

On 28 July 2016 at 16:14, Serge Rogatch via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can I ask you why you chose to patch both function entrances and exits, > rather than just patching the entrances and (in the patches) pushing on the > stack the address of __xray_FunctionExit , so that the user function returns > normally (with RETQ or POP RIP or whatever else instruction) rather than > jumping into __xray_FunctionExit? > This approach should also be faster because smaller code better fits in CPU > cache, and patching itself should run faster (because there...

...with RETQ, but rather the stack unwinder jumps through functions calling the destructors of local variable objects. > > 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). That's right -- the approach I've been thinking about (but haven't gotten to implementing yet, because of other priorities) has been to have special instrumentation at the throw and catch poin...