linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Steinar H. Gunderson" <sesse@google.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	irogers@google.com, Arnaldo Carvalho de Melo <acme@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCH v9 1/3] perf report: Support LLVM for addr2line()
Date: Tue, 30 Jul 2024 16:49:12 -0300	[thread overview]
Message-ID: <ZqlDuIj_nMVXhYou@x1> (raw)
In-Reply-To: <ZqlCIJ4khe2_xyp9@x1>

On Tue, Jul 30, 2024 at 04:42:28PM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Jul 19, 2024 at 05:00:49PM +0200, Steinar H. Gunderson wrote:
> > In addition to the existing support for libbfd and calling out to
> > an external addr2line command, add support for using libllvm directly.
> > This is both faster than libbfd, and can be enabled in distro builds
> > (the LLVM license has an explicit provision for GPLv2 compatibility).
> > Thus, it is set as the primary choice if available.
> > 
> > As an example, running perf report on a medium-size profile with
> > DWARF-based backtraces took 58 seconds with LLVM, 78 seconds with
> > libbfd, 153 seconds with external llvm-addr2line, and I got tired
> > and aborted the test after waiting for 55 minutes with external
> > bfd addr2line (which is the default for perf as compiled by distributions
> > today). Evidently, for this case, the bfd addr2line process needs
> > 18 seconds (on a 5.2 GHz Zen 3) to load the .debug ELF in question,
> > hits the 1-second timeout and gets killed during initialization,
> > getting restarted anew every time. Having an in-process addr2line
> > makes this much more robust.
> > 
> > As future extensions, libllvm can be used in many other places where
> > we currently use libbfd or other libraries:
> > 
> >  - Symbol enumeration (in particular, for PE binaries).
> >  - Demangling (including non-Itanium demangling, e.g. Microsoft
> >    or Rust).
> >  - Disassembling (perf annotate).
> > 
> > However, these are much less pressing; most people don't profile
> > PE binaries, and perf has non-bfd paths for ELF. The same with
> > demangling; the default _cxa_demangle path works fine for most
> > users, and while bfd objdump can be slow on large binaries,
> > it is possible to use --objdump=llvm-objdump to get the speed benefits.
> > (It appears LLVM-based demangling is very simple, should we want
> > that.)
> > 
> > Tested with LLVM 14, 15, 16, 18 and 19. For some reason, LLVM 12 was not
> > correctly detected using feature_check, and thus was not tested.
> > 
> > Signed-off-by: Steinar H. Gunderson <sesse@google.com>
> > Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> I'm testing this again, I thought Ian or Namhyung had made comments on
> previous versions of this patchset, no?

Unfortunately it clashed with recent patches in the capstone related
codebase, IIRC Athira's for powerpc data-type profiling.

Please take a look at what is in tmp.perf-tools-next at:

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git

I'll continue processing other patched and eventually try to fix this if
you're busy,

Thanks again for your continued work on this!

- Arnaldo

  reply	other threads:[~2024-07-30 19:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-19 15:00 [PATCH v9 1/3] perf report: Support LLVM for addr2line() Steinar H. Gunderson
2024-07-19 15:00 ` [PATCH v9 2/3] perf annotate: split out read_symbol() Steinar H. Gunderson
2024-07-19 15:00 ` [PATCH v9 3/3] perf annotate: LLVM-based disassembler Steinar H. Gunderson
2024-09-02 14:53   ` Arnaldo Carvalho de Melo
2024-09-02 14:55     ` Arnaldo Carvalho de Melo
2024-07-30 19:42 ` [PATCH v9 1/3] perf report: Support LLVM for addr2line() Arnaldo Carvalho de Melo
2024-07-30 19:49   ` Arnaldo Carvalho de Melo [this message]
2024-08-03 15:11     ` Steinar H. Gunderson
2024-09-01 10:57     ` Steinar H. Gunderson
2024-09-03 10:09       ` Arnaldo Carvalho de Melo
2024-09-03 13:14         ` Arnaldo Carvalho de Melo
2024-09-03 14:01         ` Arnaldo Carvalho de Melo
2024-09-03 14:15           ` Arnaldo Carvalho de Melo
2024-09-08 18:52             ` Steinar H. Gunderson
2024-09-09 16:42               ` Arnaldo Carvalho de Melo
2024-09-10 14:06             ` James Clark

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=ZqlDuIj_nMVXhYou@x1 \
    --to=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=sesse@google.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;
as well as URLs for NNTP newsgroup(s).