* Can perf drop libunwind support
@ 2024-10-23 21:57 Ian Rogers
2024-10-28 3:13 ` Masami Hiramatsu
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Ian Rogers @ 2024-10-23 21:57 UTC (permalink / raw)
To: linux-perf-users, Arnaldo Carvalho de Melo, Namhyung Kim,
Masami Hiramatsu, Jiri Olsa, Adrian Hunter
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?
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can perf drop libunwind support
2024-10-23 21:57 Can perf drop libunwind support Ian Rogers
@ 2024-10-28 3:13 ` Masami Hiramatsu
2024-10-28 16:03 ` Arnaldo Carvalho de Melo
2024-10-29 23:50 ` Namhyung Kim
2 siblings, 0 replies; 6+ messages in thread
From: Masami Hiramatsu @ 2024-10-28 3:13 UTC (permalink / raw)
To: Ian Rogers
Cc: linux-perf-users, Arnaldo Carvalho de Melo, Namhyung Kim,
Jiri Olsa, Adrian Hunter
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can perf drop libunwind support
2024-10-23 21:57 Can perf drop libunwind support Ian Rogers
2024-10-28 3:13 ` Masami Hiramatsu
@ 2024-10-28 16:03 ` Arnaldo Carvalho de Melo
2024-10-28 17:01 ` Frederic Weisbecker
2024-10-29 23:50 ` Namhyung Kim
2 siblings, 1 reply; 6+ messages in thread
From: Arnaldo Carvalho de Melo @ 2024-10-28 16:03 UTC (permalink / raw)
To: Ian Rogers
Cc: linux-perf-users, Namhyung Kim, Masami Hiramatsu, Jiri Olsa,
Adrian Hunter, Frederic Weisbecker
On Wed, Oct 23, 2024 at 02:57:05PM -0700, Ian Rogers 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?
Probably Jiri remembers the reasons for us to have support for both,
IIRC libunwind was a bit more mature at the time and so we decided to
have both and when some broken behaviour appears we try the other one,
in the process trying to fix the one wioth a problem?
Adding Frederic as well, this is when we started to use libunwind:
commit 6a40cd90f5deb6dec322eeb54587ae55a934db2c
Author: Jiri Olsa <jolsa@redhat.com>
Date: Tue Aug 7 15:20:44 2012 +0200
perf tools: Add libunwind dependency for DWARF CFI unwinding
Adding libunwind to be linked with perf if available. It's required
for the to get dwarf cfi unwinding support.
Also building perf with the dwarf call frame informations by default,
so that we can unwind callchains in perf itself.
Adding LIBUNWIND_DIR Makefile variable allowing user to specify
the directory with libunwind to be linked. This is used for
debug purposes.
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Original-patch-by: Frederic Weisbecker <fweisbec@gmail.com>
There is a long discussion on tests, etc on the cover letter for that
series:
https://lore.kernel.org/all/1344345647-11536-11-git-send-email-jolsa@redhat.com/T/#m0121f16278e049a2fe510c4c37884832e3c1f41d
And then later Jiri added support for libdw's unwinder:
commit 5ea8415407a76c4a85ac971ec82d110161cd77f1
Author: Jiri Olsa <jolsa@redhat.com>
Date: Wed Feb 19 16:52:57 2014 +0100
perf tools: Add libdw DWARF post unwind support
Adding libdw DWARF post unwind support, which is part of
elfutils-devel/libdw-dev package from version 0.158.
The new code is contained in unwin-libdw.c object, and implements
unwind__get_entries unwind interface function.
New Makefile variable NO_LIBDW_DWARF_UNWIND was added to control its
compilation, and is marked as disabled now. It's factored with the rest
of the Makefile unwind build code in the next patch.
Arch specific code was added for x86.
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jean Pihet <jean.pihet@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1392825179-5228-5-git-send-email-jolsa@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
But I couldn't find a discussion about why we decided to keep both, some
more investigation would be interesting to see if there are systems that
are better supported using libunwind than with libdw.
- Arnaldo
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can perf drop libunwind support
2024-10-28 16:03 ` Arnaldo Carvalho de Melo
@ 2024-10-28 17:01 ` Frederic Weisbecker
2024-10-28 19:10 ` Ian Rogers
0 siblings, 1 reply; 6+ messages in thread
From: Frederic Weisbecker @ 2024-10-28 17:01 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ian Rogers, linux-perf-users, Namhyung Kim, Masami Hiramatsu,
Jiri Olsa, Adrian Hunter
Le Mon, Oct 28, 2024 at 01:03:03PM -0300, Arnaldo Carvalho de Melo a écrit :
> On Wed, Oct 23, 2024 at 02:57:05PM -0700, Ian Rogers 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?
>
> Probably Jiri remembers the reasons for us to have support for both,
> IIRC libunwind was a bit more mature at the time and so we decided to
> have both and when some broken behaviour appears we try the other one,
> in the process trying to fix the one wioth a problem?
>
> Adding Frederic as well, this is when we started to use libunwind:
Ouch, memories are blurry... It's possible that libdw deprecated
libunwind at some point. I'm sorry I completely lost track of these
things since then :-s
thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can perf drop libunwind support
2024-10-28 17:01 ` Frederic Weisbecker
@ 2024-10-28 19:10 ` Ian Rogers
0 siblings, 0 replies; 6+ messages in thread
From: Ian Rogers @ 2024-10-28 19:10 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Arnaldo Carvalho de Melo, linux-perf-users, Namhyung Kim,
Masami Hiramatsu, Jiri Olsa, Adrian Hunter
On Mon, Oct 28, 2024 at 10:01 AM Frederic Weisbecker
<frederic@kernel.org> wrote:
>
> Le Mon, Oct 28, 2024 at 01:03:03PM -0300, Arnaldo Carvalho de Melo a écrit :
> > On Wed, Oct 23, 2024 at 02:57:05PM -0700, Ian Rogers 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?
> >
> > Probably Jiri remembers the reasons for us to have support for both,
> > IIRC libunwind was a bit more mature at the time and so we decided to
> > have both and when some broken behaviour appears we try the other one,
> > in the process trying to fix the one wioth a problem?
> >
> > Adding Frederic as well, this is when we started to use libunwind:
>
> Ouch, memories are blurry... It's possible that libdw deprecated
> libunwind at some point. I'm sorry I completely lost track of these
> things since then :-s
Thanks all.
Something that Arnaldo has mentioned is a need to reduce perf tool
dependencies. My thought is that CFI isn't that interesting to require
>1 way to provide support for it. In fact all these library
dependencies are something of a perf source base curse, where we look
to libraries or forking processes rather than doing things in the
tool. The tool pays performance and complexity penalties as a
consequence - see the removal of libcap as a dependency as an example,
also how we process addr2line output.
Masami and others have mentioned that potentially there are users for
libunwind but at the moment nobody has been able to come up with one.
Given this I think it is safe to move libunwind to being opt-in rather
than opt-out as in:
https://lore.kernel.org/lkml/20241026014305.233607-1-irogers@google.com/
I'm hoping by doing this we'll learn what the remaining libunwind
use-cases are and possibly to make it more of a default again. Of
course if it is just baggage then we should tidy that up.
Thanks,
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can perf drop libunwind support
2024-10-23 21:57 Can perf drop libunwind support Ian Rogers
2024-10-28 3:13 ` Masami Hiramatsu
2024-10-28 16:03 ` Arnaldo Carvalho de Melo
@ 2024-10-29 23:50 ` Namhyung Kim
2 siblings, 0 replies; 6+ messages in thread
From: Namhyung Kim @ 2024-10-29 23:50 UTC (permalink / raw)
To: Ian Rogers
Cc: linux-perf-users, Arnaldo Carvalho de Melo, Masami Hiramatsu,
Jiri Olsa, Adrian Hunter
Hi Ian,
On Wed, Oct 23, 2024 at 02:57:05PM -0700, Ian Rogers 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?
>
> 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.
I'm ok with removing libunwind to reduce the maintenance burden.
In general, we'd better not have multiple libraries for the same
purpose. Recently we added libllvm support, then it might replace
libelf, libdw and libcapstone someday. :)
Thanks,
Namhyung
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-10-29 23:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-23 21:57 Can perf drop libunwind support Ian Rogers
2024-10-28 3:13 ` Masami Hiramatsu
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
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).