linux-tools: can perf be linked against libbfd, maybe statically?

Bug #1894407 reported by Jay Freeman (saurik)
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

The perf tool has an optional dependency on libbfd. Per Debian policy, and due to some situation involving parallel installations of this library, no packages should link dynamically against libbfd. In the past, bugs have been filed to link perf statically against libbfd in bug 783660 (from 2011) and then to just not link against it at all in bug 1748922 (from 2018) and bug 1828234 (from 2019). The argument was made that perf does not need this dependency, as perf can use libiberty as an alternative to demangle C++ names.

However, that is not the only thing perf is using libbfd for: the other is to implement an inlined version of addr2line. This was part of an important patchset from 2013 that strove to improve the performance of perf. In my case, I ran my program for all of 30 seconds, generating a 163M large trace, and have been waiting almost an hour for the events to process... and it is only a third of the way done; what I see it doing is spawning, over and over and over again, addr2line, which it wouldn't do if linked against libbfd.

https://lore.kernel.org/patchwork/patch/413455/

Is it possible to link perf statically against libbfd, in order to let it use the in-process implementation of addr2line? That is the solution that I've understood for other packages, such as oprofile in bug 426614 and bug 588033. Doing a quick grep of the code of perf for HAVE_LIBBFD_SUPPORT, it seems like bpf disassembly support is also dependent on libbfd (and so while it is great that Ubuntu's build of perf has been compiled against libbpf, it seems like that functionality is being hampered by the lack of linking libbfd).

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1894407

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Jay Freeman (saurik) (saurik) wrote :

I am leaving a comment to the effect that my issue is not something for which logs are relevant.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Seth Forshee (sforshee) wrote :

It's not just about installing different versions of linux-tools. libbfd has no guarantee of a stable ABI/API, which makes it problematic for external packages to link against them. Thus it is against policy to link against libbfd in Ubuntu, and we simply cannot link perf against it as long as this is the situation.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
Jay Freeman (saurik) (saurik) wrote :

I not only understood that but explicitly stated as such; not just the reasoning, but also the policy... however, that only applies to dynamic linking: other packages--as I also explicitly demonstrated--link against libbfd statically for this very reason; are you saying that there has been a misunderstanding of the policy and they are out of compliance, and that I should file a bug against them--for example, oprofile--citing that "Seth Forshee has stated this package must not be linking against libbfd"?

Revision history for this message
Jay Freeman (saurik) (saurik) wrote :

(Actually, I'm frustrated enough I'm just going to say it explicitly, rather than indirectly: it looks like you didn't read my comment, as even the thrust of your response--that "it's not just about installing different versions of linux-tools"--isn't something I even hinted at as the reason; the most charitable explanation is that you took "parallel installations of this library" to somehow mean linux-tools and not libbfd, but that explanation doesn't help that you then try to inform me of a policy I explained, seem to have the policy wrong, and then didn't respond to any of the other points I made.)

Revision history for this message
Nikhil Benesch (nikhil-benesch) wrote :

I too would very much like to see this fixed. As it stands `perf report` is unusable on large binaries on Ubuntu.

Seth, I think Jay's arguments are compelling. Do you agree? If I prepared a patch, would that be helpful?

Revision history for this message
Nikhil Benesch (nikhil-benesch) wrote :

As it turns out Ubuntu *did* used to link perf statically: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/783660

So I really don't understand the objection here.

Revision history for this message
Tony Garnock-Jones (tonyg) wrote :

I've prepared a patch that uses a single long-running instance of addr2line for each dso, instead of one per address request. It dramatically speeds up e.g. `perf script` operation (I don't know if it solves OP's problem but it could be relevant!).

Discussion on linux-perf-users mailing list: https://<email address hidden>/

Background: https://eighty-twenty.org/2021/09/09/perf-addr2line-speed-improvement

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.