Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1271960
| From | "Wangnan (F)" <wangnan0@huawei.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction |
| Date | 2015-11-18 10:00 +0100 |
| Message-ID | <qw6KS-Af-7@gated-at.bofh.it> (permalink) |
| References | <qw5lL-8cX-3@gated-at.bofh.it> <qw68a-jO-27@gated-at.bofh.it> <qw6hQ-nn-15@gated-at.bofh.it> <qw6KS-Af-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-18 08:30 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-18 09:20 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Ingo Molnar <mingo@kernel.org> - 2015-11-18 09:30 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-18 10:00 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Ingo Molnar <mingo@kernel.org> - 2015-11-19 07:40 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-19 07:50 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Ingo Molnar <mingo@kernel.org> - 2015-11-19 11:30 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-19 11:50 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Peter Zijlstra <peterz@infradead.org> - 2015-11-19 12:30 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Peter Zijlstra <peterz@infradead.org> - 2015-11-19 12:30 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Ingo Molnar <mingo@kernel.org> - 2015-11-27 09:40 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Peter Zijlstra <peterz@infradead.org> - 2015-11-30 10:30 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-18 10:10 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction Jiri Olsa <jolsa@redhat.com> - 2015-11-18 09:50 +0100
Re: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction "Wangnan (F)" <wangnan0@huawei.com> - 2015-11-18 10:20 +0100
csiph-web