linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milian Wolff <milian.wolff@kdab.com>
To: dsahern@gmail.com
Cc: acme@kernel.org, linux-perf-users@vger.kernel.org, hekuang@huawei.com
Subject: Re: Cross platform perf reporting
Date: Mon, 15 Aug 2016 17:22:55 +0200	[thread overview]
Message-ID: <7508364.ZKHyXyzSjv@milian-kdab2> (raw)
In-Reply-To: <099059ce-5a77-b63e-679b-a6b4519f5ba7@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7792 bytes --]

On Monday, August 15, 2016 8:42:12 AM CEST David Ahern wrote:
> On 8/15/16 6:20 AM, Milian Wolff wrote:
> >> That is the --symfs David talked about, no?
> >> 
> >> [acme@jouet linux]$ perf report -h symfs
> >> 
> >>  Usage: perf report [<options>]
> >>  
> >>         --symfs <directory>
> >>         
> >>                           Look for files with symbols relative to this
> >> 
> >> directory
> > 
> > Yes, symfs sounds exactly like what I was looking for. I have now tested
> > this,
> > and seem to hit some issues with it:
> -----8<-----
> 
> > Setting symfs:
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > milian@milian-kdab2:/tmp$ locate libc-2.19.so
> > /home/milian/.debug/lib/arm-linux-gnueabihf/libc-2.19.so
> > /home/milian/.debug/lib/arm-linux-gnueabihf/libc-2.19.so/
> > 457c5918872338e1b82bf8bf41ae9f55b34604ea
> > /home/milian/.debug/lib/arm-linux-gnueabihf/libc-2.19.so/
> > 457c5918872338e1b82bf8bf41ae9f55b34604ea/elf
> > /home/milian/.debug/lib/arm-linux-gnueabihf/libc-2.19.so/
> > 457c5918872338e1b82bf8bf41ae9f55b34604ea/probes
> > /ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/lib/ar
> > m- linux-gnueabihf/libc-2.19.so
> > milian@milian-kdab2:/tmp$ strace -e file -f perf report
> > --symfs=/ssd/milian/
> > projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/ --stdio -s
> > sym,srcline |& grep libc-2.19
> > open("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = 8
> > stat("/lib/arm-linux-gnueabihf/libc-2.19.so", 0x7ffc4da5e740) = -1 ENOENT
> > (No such file or directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", {st_mode=S_IFREG|0755,
> > st_size=911068, ...}) = 0
> > open("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = 9
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", {st_mode=S_IFREG|0755,
> > st_size=911068, ...}) = 0
> > open("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = 9
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // usr/lib/debug/lib/arm-linux-gnueabihf/libc-2.19.so.debug",
> > 0x7ffc4da5e740) = -1 ENOENT (No such file or directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // usr/lib/debug/lib/arm-linux-gnueabihf/libc-2.19.so", 0x7ffc4da5e740) =
> > -1 ENOENT (No such file or directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", {st_mode=S_IFREG|0755,
> > st_size=911068, ...}) = 0
> > open("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = 10
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > // lib/arm-linux-gnueabihf/.debug/libc-2.19.so", 0x7ffc4da5e740) = -1
> > ENOENT (No such file or directory)
> > open("/lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so
> > open("/lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so
> > open("/lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so
> > open("/lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so
> > open("/lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so
> > open("/lib/arm-linux-gnueabihf/libc-2.19.so", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so
> > 
> >      0.25%     0.25%  [.] 0x000000000005336c  libc-2.19.so[5336c]
> >      0.25%     0.00%  [.] 0xffffffff4936136c  libc-2.19.so[ffffffff4936136
> >      0.24%     0.24%  [.] 0x0000000000053422  libc-2.19.so[53422]
> >      0.24%     0.00%  [.] 0xffffffff49361422  libc-2.19.so[ffffffff4936142
> >      0.21%     0.21%  [.] 0x0000000000053664  libc-2.19.so[53664]
> >      0.21%     0.00%  [.] 0xffffffff49361664  libc-2.19.so[ffffffff4936166
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Note how it does look into symfs sometimes, but not everywhere...
> 
> It should not open files outside of the symfs tree.

But apparently that is what happens.

> If you note perf does find libc in the symfs 3 times but it is not finding
> the symbol information it wants.

I only see that it fails to get addr2line debug information from paths 
*outside* of the symfs: 

addr2line_init failed for /lib/arm-linux-gnueabihf/libc-2.19.so

> > To make things worse, it seems to break the buildid lookup, i.e. when you
> > get samples in a file that you deployed manually to a target, which is
> > not included in your sysroot that you pass to symfs:
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<snip>
> > $ strace -e file -f perf report --symfs=/ssd/milian/projects/pandaboard/
> > debian-8.5-minimal-armhf-2016-06-06/ --stdio -s sym,srcline |& grep
> > particles
> > 
> > open("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > //
> > root/particles", O_RDONLY) = -1 ENOENT (No such file or directory)
> > stat("/root/particles", 0x7ffe7535bf40) = -1 EACCES (Permission denied)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > //
> > root/particles", 0x7ffe7535bec0) = -1 ENOENT (No such file or directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > //
> > usr/lib/debug/root/particles.debug", 0x7ffe7535bf40) = -1 ENOENT (No such
> > file or directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > //
> > usr/lib/debug/root/particles", 0x7ffe7535bf40) = -1 ENOENT (No such file
> > or
> > directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > //
> > root/particles", 0x7ffe7535bf40) = -1 ENOENT (No such file or directory)
> > stat("/ssd/milian/projects/pandaboard/debian-8.5-minimal-armhf-2016-06-06/
> > //
> > root/.debug/particles", 0x7ffe7535bf40) = -1 ENOENT (No such file or
> > directory)
> > /root/particles with build id 1c10a17afa25337ab368f8d9e690184e536c6563 not
> > found, continuing without symbols
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > Note how the above does not look for the buildid in my ~/.debug anymore...
> 
> With symfs every file should be below the symfs root directory, including
> build id files.

So I should unpack the perf archive on top of my sysroot?

That sounds like a bad idea, considering that I would then get clashes between 
e.g. the actual /lib/libc.so.6 in my sysroot and the debug info that is in a 
folder called /lib/libc.so.6/ in ~/.debug. And from the strace output above, 
it does not look like perf would look into a .debug folder directly in 
$symfs/.

It also does not seem to be possible to pass multiple symfs directories, which 
could also solve the issue for me. I.e. pass both a path to the sysroot, and 
an additional path to wherever I unpacked the perf archive to.

Thanks
-- 
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]

  reply	other threads:[~2016-08-15 15:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-12 12:22 Cross platform perf reporting Milian Wolff
2016-08-12 14:38 ` David Ahern
2016-08-12 15:10 ` Milian Wolff
2016-08-12 15:31   ` Arnaldo Carvalho de Melo
2016-08-15 12:20     ` Milian Wolff
2016-08-15 14:42       ` David Ahern
2016-08-15 15:22         ` Milian Wolff [this message]
2016-08-15 16:08           ` David Ahern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7508364.ZKHyXyzSjv@milian-kdab2 \
    --to=milian.wolff@kdab.com \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=hekuang@huawei.com \
    --cc=linux-perf-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).