1 # This reproduces a bug with instrumentation when trying to count calls
2 # when the target address is computed with a reference to the stack pointer.
3 # Our instrumentation code uses the stack to save registers to be
4 # transparent with the instrumented code, but we end up updating the stack
5 # pointer while doing so, which affects this target address calculation.
6 # The solution is to temporarily fix RSP. Check that we correctly instrument
9 # REQUIRES: system-linux,bolt-runtime
11 # RUN: llvm-mc -filetype=obj -triple x86_64-unknown-unknown \
13 # RUN: %clang %cflags -no-pie %t.o -o %t.exe -Wl,-q
15 # RUN: llvm-bolt %t.exe --instrument --instrumentation-file=%t.fdata \
16 # RUN: -o %t.instrumented
18 # Instrumented program needs to finish returning zero
19 # RUN: %t.instrumented arg1 arg2
21 # Test that the instrumented data makes sense
22 # RUN: llvm-bolt %t.exe -o %t.bolted --data %t.fdata \
23 # RUN: --reorder-blocks=ext-tsp --reorder-functions=hfsort+ \
24 # RUN: --print-only=main --print-finalized | FileCheck %s
26 # RUN: %t.bolted arg1 arg2
28 # Check that our indirect call has 1 hit recorded in the fdata file and that
29 # this was processed correctly by BOLT
30 # CHECK: callq *0x18(%rsp) # CallProfile: 1 (0 misses) :
31 # CHECK-NEXT: { targetFunc: 1 (0 misses) }
41 pushq
%rax
# We save the target function address in the stack
42 subq $
0x18, %rsp
# Set up a dummy stack frame
44 jb
.LBBerror # Add control flow so we don't have a trivial case
46 callq
*0x18(%rsp
) # Indirect call using %rsp
56 movq $
1, %rax
# Finish with an error if we go this path
61 .type targetFunc, %function
66 .size targetFunc, .-targetFunc