lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5775CFF5.6040802@huawei.com>
Date:	Fri, 1 Jul 2016 10:05:41 +0800
From:	Hekuang <hekuang@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	Wang Nan <wangnan0@...wei.com>, Jiri Olsa <jolsa@...nel.org>,
	"Peter Zijlstra" <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: perf unwind: Odd message about x86 unwind

hi

在 2016/6/30 20:06, Arnaldo Carvalho de Melo 写道:
> Hi He,
>
> 	While testing a patch by Peter Zijlstra to the --stdio
> annotation code I came accross these messages:
>
> [acme@...et linux]$ perf annotate __vdso_gettimeofday 2>&1 | head -20
> unwind: target platform=x86 is not supported
> unwind: target platform=x86 is not supported
> unwind: target platform=x86 is not supported
> unwind: target platform=x86 is not supported
>   Percent |	Source code & Disassembly of perf-vdso.so-E5tFUx for cycles:u
> -----------------------------------------------------------------------------
>           :
>           :
>           :
>           :	Disassembly of section .text:
>           :
>           :	0000000000000cd0 <__vdso_gettimeofday@@LINUX_2.6>:
>      0.00 :	  cd0:   push   %rbp
>      0.00 :	  cd1:   mov    %rsp,%rbp
>      0.00 :	  cd4:   push   %r15
>      0.00 :	  cd6:   push   %r14
>      0.00 :	  cd8:   push   %r13
>      0.00 :	  cda:   push   %r12
>      0.00 :	  cdc:   push   %rbx
>      0.00 :	  cdd:   sub    $0x10,%rsp
> [acme@...et linux]$
>
> And bisected it down to:
>
> commit 52ffe0ff02fc053a025c381d5808e9ecd3206dfe
> Author: He Kuang <hekuang@...wei.com>
> Date:   Fri Jun 3 03:33:22 2016 +0000
>
>      perf callchain: Support x86 target platform
>      
>      Support x86(32-bit) cross platform callchain unwind.
>      
>      Signed-off-by: He Kuang <hekuang@...wei.com>
>      Acked-by: Jiri Olsa <jolsa@...nel.org>
>
> --------------------------------------------------
>
> The source code where this message is emitted is:
>
> struct unwind_libunwind_ops __weak *local_unwind_libunwind_ops;
> <SNIP>
> unwind__prepare_access()
> {
> 	struct unwind_libunwind_ops *ops = local_unwind_libunwind_ops;
> <SNIP>
> 	if (!strcmp(arch, "x86")) {
>                  if (dso_type != DSO__TYPE_64BIT)
>                          ops = x86_32_unwind_libunwind_ops;
>          }
> <SNIP>
>          if (!ops) {
>                  pr_err("unwind: target platform=%s is not supported\n", arch);
>                  return -1;
>          }
>
> So, this should fallback to local_unwind_libunwind_ops, why is this not being
> set properly?
>
> Feature detection says:
>
> ...                     libunwind: [ on  ]
> ...            libdw-dwarf-unwind: [ on  ]
>
> This is:
>
> [acme@...et linux]$ uname -a
> Linux jouet 4.5.7-300.fc24.x86_64 #1 SMP Wed Jun 8 18:12:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linuxo
>
> Can you please check this?

I think it's because of the perf.data contains both 32bit/64bit
threads while perf is only build with local unwind(unwind for
x86_64).

Then I have a simple test for this:

   $ file hello_x86_64
   hello_x86_64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 3.0.0, 
BuildID[sha1]=adc94932cbcb2be80f3b62df530b8c109f40478a, not strippe

   $ file hello_i686
   hello_i686: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 4.5.0, not stripped

   $ perf record -o perf.data.x86_64_singlethread    hello_x86_64
   $ perf record -o perf.data.x86_64_allcpu       -a hello_x86_64
   $ perf record -o perf.data.i686_singlethread      hello_i686
   $ perf record -o perf.data.i686_allcpu         -a hello_i686

Now I get 4 perf.data files:

   ID    name                32bit        64bit

   1    perf.data.x86_64_singlethread    N        Y
   2    perf.data.x86_64_allcpu        N        Y
   3    perf.data.i686_singlethread    Y        N
   4    perf.data.i686_allcpu        Y        Y

Because perf only supports local unwind(for x86_64), cases
contain 32bit thread should show the warnings, i.e. case3 and
case4. And perf.data contains only 32bit threads will show nothing
except the warnings while the one contains both 32bit/64bit will
show warnings for 32bit thread and annoate the 64bit thread.

Then check:

   $ perf annotate -i perf.data.x86_64_singlethread

    Percent |      Source code & Disassembly of hello for cycles:pp
   ----------------------------------------------------------------
            :
            :
            :
            :      Disassembly of section .text:
            :
            :      00000000004005c0 <fib>:
            :      fib():
            :      #endif

   $ perf annotate -i perf.data.x86_64_allcpu

   Percent |      Source code & Disassembly of hello for cycles:pp
   ----------------------------------------------------------------
            :
            :
            :
            :      Disassembly of section .text:
            :
            :      00000000004005c0 <fib>:
            :      fib():
            :      #endif
            :
            :      volatile int z = 0;
            :
            :      int fib(int x)

   $ perf annotate -i perf.data.i686_singlethread

   unwind: target platform=x86 is not supported
   unwind: target platform=x86 is not supported
   unwind: target platform=x86 is not supported

   $ perf annotate -i perf.data.i686_allcpu

   unwind: target platform=x86 is not supported
   unwind: target platform=x86 is not supported
   unwind: target platform=x86 is not supported

   Percent |      Source code & Disassembly of perf for cycles:pp
   ---------------------------------------------------------------
   :
   :
   :
   :      Disassembly of section .text:
   :
   :      0000000000442a8f <record__mmap_read>:
   :      record__mmap_read():
   :
   :              return backward_rb_find_range(data, mask, head, start, 
end);
   :      }

The result is the same as we expected, so if your case matches
the case4, the result is right. But I think we can improve the
warning message for not confusing the users.

Thank you.

> - Arnaldo
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ