lkml.org 
[lkml]   [2015]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction


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.




\
 
 \ /
  Last update: 2015-11-18 10:21    [W:0.189 / U:0.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site