All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.