From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: linux-perf-users <linux-perf-users@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: Can perf drop libunwind support
Date: Mon, 28 Oct 2024 12:13:33 +0900 [thread overview]
Message-ID: <20241028121333.92aaef3cc934432ace2e227c@kernel.org> (raw)
In-Reply-To: <CAP-5=fUXkp-d7gkzX4eF+nbjb2978dZsiHZ9abGHN=BN1qAcbg@mail.gmail.com>
On Wed, 23 Oct 2024 14:57:05 -0700
Ian Rogers <irogers@google.com> wrote:
> Hi,
>
> perf wants to build with BPF support these days. libbpf has a
> dependency on libelf, part of elfutils. libdw is also part of elfutils
> and amongst other things provides unwinding support. My understanding
> is libdw unwinding is used by perf in preference to libunwind when
> present. My suspicion is that libunwind is being feature tested,
> linked against but then seldom or never used. Given this could perf
> drop libunwind support in order to simplify the code base?
libunwind focuses on unwinding but libdw (elfutils-dev) is more general,
so if we can unwind only with libdw, we can remove libunwind dependency.
Here my concern is that the libunwind is smaller than libdw, thus
any small system may still need libunwind support. Can we warn when
using libunwind at this point? After all users move to libdw we
can safely remove it.
Thank you,
>
> Possible savings:
> - remove libunwind's 8 feature tests
> - removal of 10 arch or not libunwind C files in perf
> - removal of libunwind #ifdef-ed code throughout common files.
>
> Thanks,
> Ian
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2024-10-28 3:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 21:57 Can perf drop libunwind support Ian Rogers
2024-10-28 3:13 ` Masami Hiramatsu [this message]
2024-10-28 16:03 ` Arnaldo Carvalho de Melo
2024-10-28 17:01 ` Frederic Weisbecker
2024-10-28 19:10 ` Ian Rogers
2024-10-29 23:50 ` Namhyung Kim
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=20241028121333.92aaef3cc934432ace2e227c@kernel.org \
--to=mhiramat@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@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).