From: valentin.grigorev@jetbrains.com (Valentin Grigorev)
Subject: [lttng-dev] LTTng user-space callstacks
Date: Fri, 27 Mar 2020 16:44:19 +0300 [thread overview]
Message-ID: <CABhb4usOZOFUwQL85c5wW5K5VSMXx+CVwFmBb_ia+wJ1TJsxVw@mail.gmail.com> (raw)
In-Reply-To: <1834419.usQuhbGJ8B@agathebauer>
Yeah, as far as I know, perf [1] is successfully using libunwind to provide
callstacks. Probably, LTTng team should think about it too, if there are no
serious obstacles.
[1]: https://perf.wiki.kernel.org/index.php/Main_Page
Best regards,
Valentin Grigorev
On Thu, Mar 26, 2020 at 11:53 PM Milian Wolff <milian.wolff at kdab.com> wrote:
> On Donnerstag, 26. M?rz 2020 20:41:17 CET Mathieu Desnoyers via lttng-dev
> wrote:
> > ----- On Mar 26, 2020, at 1:39 PM, lttng-dev <lttng-dev at lists.lttng.org>
>
> wrote:
> > > Hello!
> > >
> > > Currently, callstack collection in LTTng is only available for
> > > kernel-space
> > > events with context fields callstack-kernel and callstack-user .
> > >
> > > Is it expected that callstack collection for LTTng-UST will be added
> too?
> > > And if it is expected, then how soon?
> >
> > Hi Valentin,
> >
> > It is something that would be interesting and useful, but a lot of work
> > would be needed to have stack-walking this is fast enough and reentrant
> wrt
> > signal handlers. Unfortunately, the backtrace(3) functions do not meet
> > those requirements.
> >
> > Also, for gathering user-space callstacks from the kernel tracer, it only
> > works if all user-space is compiled with frame pointers. This is also a
> > limitation that would require a lot of work to overcome neatly.
> >
> > None of those features are currently on any roadmap due to lack of
> customers
> > showing interest in getting this done.
>
> libunwind [1] should meet the requirements you need. It is high
> performance
> thanks to extensive caching, signal safe and does not rely on frame
> pointers.
>
> [1]: https://github.com/libunwind/libunwind
>
> --
> Milian Wolff | milian.wolff at kdab.com | Senior Software Engineer
> KDAB (Deutschland) GmbH, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20200327/f902fb81/attachment.htm>
next prev parent reply other threads:[~2020-03-27 13:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-26 17:39 Valentin Grigorev
2020-03-26 19:41 ` Mathieu Desnoyers
2020-03-26 20:52 ` Milian Wolff
2020-03-27 13:44 ` Valentin Grigorev [this message]
2020-03-27 13:55 ` Mathieu Desnoyers
2020-03-27 15:05 ` Valentin Grigorev
2020-03-27 17:18 ` 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=CABhb4usOZOFUwQL85c5wW5K5VSMXx+CVwFmBb_ia+wJ1TJsxVw@mail.gmail.com \
--to=valentin.grigorev@jetbrains.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