Displaying 6 results from an estimated 6 matches for "__xray_functionentry".
2016 Jul 28
4
XRay: Demo on x86_64/Linux almost done; some questions.
...(otherwise r4 may not get preserved)
PUSH {r4, lr}
ADR lr, #16 ; relative offset of after_entrance_traced
; r4 must be preserved by the instrumented function, so that
; __xray_FunctionExit gets function ID in r4 too
LDR r4, [pc, #0] ; offset of function ID stored by the patching mechanism
; call __xray_FunctionEntry (returning to after_entrance_traced)
LDR pc, [pc, #0] ; use the address stored by the patching mechanism
.word <32-bit function ID>
.word <32-bit address of __xray_FunctionEntry>
.word <32-bit address of __xray_FunctionExit>
after_entrance_traced:
; Make the instrumented function...
2016 Jul 29
0
XRay: Demo on x86_64/Linux almost done; some questions.
...served)
> PUSH {r4, lr}
> ADR lr, #16 ; relative offset of after_entrance_traced
> ; r4 must be preserved by the instrumented function, so that
> ; __xray_FunctionExit gets function ID in r4 too
> LDR r4, [pc, #0] ; offset of function ID stored by the patching mechanism
> ; call __xray_FunctionEntry (returning to after_entrance_traced)
> LDR pc, [pc, #0] ; use the address stored by the patching mechanism
> .word <32-bit function ID>
> .word <32-bit address of __xray_FunctionEntry>
> .word <32-bit address of __xray_FunctionExit>
> after_entrance_traced:
> ; M...
2016 Jul 29
2
XRay: Demo on x86_64/Linux almost done; some questions.
...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.
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
> <ll...
2016 Jul 29
1
XRay: Demo on x86_64/Linux almost done; some questions.
...}
> > ADR lr, #16 ; relative offset of after_entrance_traced
> > ; r4 must be preserved by the instrumented function, so that
> > ; __xray_FunctionExit gets function ID in r4 too
> > LDR r4, [pc, #0] ; offset of function ID stored by the patching mechanism
> > ; call __xray_FunctionEntry (returning to after_entrance_traced)
> > LDR pc, [pc, #0] ; use the address stored by the patching mechanism
> > .word <32-bit function ID>
> > .word <32-bit address of __xray_FunctionEntry>
> > .word <32-bit address of __xray_FunctionExit>
> > after_...
2016 Jul 29
0
XRay: Demo on x86_64/Linux almost done; some questions.
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)
2016 Jul 30
1
XRay: Demo on x86_64/Linux almost done; some questions.
...ase because the function doesn'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).
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...