Re: perf call stacks on 32bit ARM v7

[Milian Wolff <milian.wolff@kdab.com>]

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

On Tuesday, October 4, 2016 10:41:25 AM CEST Jean Pihet wrote:
> On Sun, Oct 2, 2016 at 11:12 PM, Milian Wolff <milian.wolff@kdab.com> wrote:
> > On Freitag, 30. September 2016 09:32:44 CEST Jean Pihet wrote:
> >> Hi,
> >> 
> >> On Thu, Sep 29, 2016 at 12:33 PM, Milian Wolff <milian.wolff@kdab.com>
> > 
> > wrote:
> >> > On Donnerstag, 29. September 2016 09:39:51 CEST Jean Pihet wrote:
> >> >> Hi Milian, Wangnan,
> >> >> 
> >> >> I am pretty busy this week. Let me check and come back to you next
> >> >> week.
> >> > 
> >> > Sure, take your time - much appreciated!
> >> > 
> >> >> PS: did you check the detailed instructions from the Linaro wiki
> >> >> pages?
> >> >> These are linked from the Fosdem presentation slides.
> >> > 
> >> > You mean this page, right:
> >> > 
> >> > https://wiki.linaro.org/KenWerner/Sandbox/libunwind
> >> 
> >> I mean
> >> https://wiki.linaro.org/LEG/Engineering/TOOLS/perf-callstack-unwinding
> >> where the details about installation, compilation etc. are found.
> >> 
> >> In short, DWARF unwinding on ARMv7 should work out of the box. You
> >> need libunwind, the correct kernel config options and perf installed.
> >> As you are mentioning the downside is the size of the generated trace
> >> which can be a limitation on embedded systems. Some parameters can be
> >> used to control the size of the generated trace (-F).
> > 
> > No, I mean the size of the application code when debug symbols are added:
> > 
> > tmp$ du -hs libQt5Core.so.5.7.1
> > 63M     libQt5Core.so.5.7.1
> > tmp$ strip libQt5Core.so.5.7.1
> > tmp$ du -hs libQt5Core.so.5.7.1
> > 4.8M    libQt5Core.so.5.7.1
> > 
> > And this is just one library involved of many in the applications I have
> > to
> > deal with regularly. I just had a case where the target platform had about
> > 50MB storage space free. I resorted to connecting an USB drive to load the
> > application code with debug symbols from. But this changes the performance
> > behavior of the application, as the code is not loaded anymore from the
> > often excruciatingly slow on-board flash drive.
> 
> That is correct. You need some space for the debug symbols and also
> for the trace generation (I am using the RAM for speed reasons).

Sure, but in principle we could record samples in DWARF mode without debug 
symobls on the target, and then do the unwinding on a different host that 
actually has the debug symbols - right? I.e. once perf actually supports this, 
like it does for x86_64, x86_32 and arm64, as implemented by He Kuang.

> >> > That does not mention perf at all, and only talks about libunwind. Note
> >> > how
> >> > your talk, and the wiki, say .exidx unwinding using libunwind works.
> >> > But
> >> > your slides also explicitly say that this mechanism is not supported by
> >> > perf, yet. I would like to know the reason for that, or whether this is
> >> > outdated information.
> >> 
> >> I do not recall the details but .exidx is not supported on ARM,
> >> because of the compiler that does not generate the info in the
> >> binaries (you can check the ELF sections for it)
> > 
> > If I compile with -funwind-tables, then I do get the .exidx section, see
> > this link I posted earlier:
> > 
> > https://wiki.linaro.org/KenWerner/Sandbox/libunwind
> > 
> >> or the kernel does not unwind the info.
> > 
> > That sounds more like the culprit - can someone confirm, that:
> > 
> > - for frame-pointer based unwinding, perf unwinds the stacks in kernel
> > space - whereas dwarf-based unwinding copies the stack together with the
> > samples into the perf.data, and does the unwinding later on
> 
> Correct! This dwarf unwinding method generates a lot of trace data.
> Also the real time trace decoding is not possible.
> 
> > So one would need to either
> > 
> > - add .exidx unwinding support into the kernel
> > - copy whatever is required into perf.data and do the unwinding later on
> > 
> >   can someone clarify what is actually required to do that?
> 
> That requires a more extensive analysis.
> 
> As you know I am a freelance consultant and could work on that topic,
> as I did for Linaro before.

It would indeed be nice if someone could contract you to fill these gaps.

Cheers

-- 
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 --]