linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milian Wolff <milian.wolff@kdab.com>
To: jean.pihet@newoldbits.com
Cc: perf group <linux-perf-users@vger.kernel.org>, wangnan0@huawei.com
Subject: perf call stacks on 32bit ARM v7
Date: Tue, 27 Sep 2016 23:25:20 +0200	[thread overview]
Message-ID: <4233607.GXAFRqVoOG@agathebauer> (raw)

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

Hello Jean, others.

Can someone please clarify the requirements for getting perf to properly 
unwind the call stack on 32bit ARM v7?

Looking at [1], it seems that I need either (a) frame pointers, or (b) DWARF 
debug information. Because (a) is often not available, and (b) is too large 
for small flash drives on embedded - how do I use perf with split debug 
information files? I.e. I have tries to record on the arm board using DWARF:

arm-v7$ perf record --call-graph dwarf ...

Then transferred the perf.data file over to my host machine. Perf archive said 
that no build-id's could be found, so I'm not using that. Instead, I try to 
ask perf to find the split debug packes using symfs:

x86-64$ perf report --symfs ... -g graph

But that does not work and I'm not seeing any backtraces. Stracing the report, 
I don't see it even trying to access files - how can I debug this and figure 
out what I'm supposed to be using?

Also according to [1], ARM .exidx unwind tables (c) are not supported by perf 
- is that still the case? If so, what is holding back support for that in 
perf, considering that libunwind supposedly supports unwinding using that 
information?

Thanks

[1]: https://archive.fosdem.org/2015/schedule/event/arm_perf/attachments/
slides/601/export/events/attachments/arm_perf/slides/601/
Fosdem_2015_perf_status_on_ARM_and_ARM64.pdf

-- 
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-09-27 21:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-27 21:25 Milian Wolff [this message]
2016-09-28  1:43 ` perf call stacks on 32bit ARM v7 Wangnan (F)
     [not found]   ` <CAORVsuUB1AwtZxnNS-Z5pXdcDfrD=GWr43C=NMZsVq=CdqR5xA@mail.gmail.com>
2016-09-29 10:33     ` Milian Wolff
2016-09-30  7:32       ` Jean Pihet
2016-10-02 21:12         ` Milian Wolff
2016-10-04  8:41           ` Jean Pihet
2016-10-04 12:01             ` Milian Wolff

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=4233607.GXAFRqVoOG@agathebauer \
    --to=milian.wolff@kdab.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=wangnan0@huawei.com \
    /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).