Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction

["Wangnan (F)" <wangnan0@huawei.com>]

On 2015/11/18 16:42, Wangnan (F) wrote:
>
>
> On 2015/11/18 16:20, Ingo Molnar wrote:
>> * Wangnan (F) <wangnan0@huawei.com> wrote:
>>
>>> On 2015/11/18 15:20, Wangnan (F) wrote:
>>>> Hi all,
>>>>
>>>> When analysising Jiri's patchset [1] I found a dwarf unwind problem.
>>>> On x86 platform, when sample is at a 'callq' instruction, dwarf based
>>>> stack unwind always fail.
>>>>
>>>> I compile a small C source file with debug information, turn off
>>>> frame pointer and disable optimization:
>>>>
>>>> $ gcc -g -O0 -fomit-frame-pointer ./test_dwarf_unwind.c -o
>>>> ./test_dwarf_unwind
>>> For whom want to test it: here is the test code I used.
>>>
>>> #include <stdio.h>
>>> #include <unistd.h>
>>> #include <sys/time.h>
>>>
>>> static volatile int x = 0;
>>>
>>> int funcc(void)
>>> {
>>>      struct timeval tv1, tv2;
>>>      unsigned long us1, us2;
>>>
>>>      gettimeofday(&tv1, NULL);
>>>
>>>      us1 = tv1.tv_sec * 1000000 + tv1.tv_usec;
>>>
>>>      while(1) {
>>>          x = x + 100;
>>>          gettimeofday(&tv2, NULL);
>>>          us2 = tv2.tv_sec * 1000000 + tv2.tv_usec;
>>>          if (us2 - us1 >= 3000000)
>>>              break;
>>>      }
>>>      return x;
>>> }
>>> int funcb(void) { return funcc();}
>>> int funca(void) { return funcb();}
>>> int main() { funca(); return 0;}
>> What CPU model is this, and what event was used - PEBS perhaps? This 
>> might be some
>> sort of PMU sampling bug/quirk/misfeature - or perhaps a kernel side 
>> fixup that
>> went bad?
>
> $ cat /proc/cpuinfo
> processor    : 0
> vendor_id    : GenuineIntel
> cpu family    : 6
> model        : 60
> model name    : Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
> stepping    : 3
> microcode    : 0x1c
> cpu MHz        : 3600.000
> cache size    : 8192 KB
> physical id    : 0
> siblings    : 8
> core id        : 0
> cpu cores    : 4
> apicid        : 0
> initial apicid    : 0
> fpu        : yes
> fpu_exception    : yes
> cpuid level    : 13
> wp        : yes
> flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts 
> rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq 
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm 
> pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave 
> avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow 
> vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 
> erms invpcid xsaveopt
> bugs        :
> bogomips    : 7183.88
> clflush size    : 64
> cache_alignment    : 64
> address sizes    : 39 bits physical, 48 bits virtual
> power management:
>
>
> perf cmdline is
>
> # ./pref record  -g -F 9 --call-graph dwarf ./test_dwarf_unwind
>
> Use default events, precise_ip == 2 so uses PEBS.
>

Testetd 'cycles', 'cycles:p' and 'cycles:pp'. Only 'cycles:pp' captures
sample at callq. So maybe a PEBS problem?

Thank you.