All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Darren Kenny <darren.kenny@oracle.com>,
	Eric Saint-Etienne <eric.saintetienne@gmail.com>
Subject: Re: [PATCH v3] perf symbols: Cannot disassemble some routines when debuginfo present
Date: Wed, 28 Nov 2018 17:19:20 +0100	[thread overview]
Message-ID: <20181128161920.GD13589@krava> (raw)
In-Reply-To: <1543422934-1228-1-git-send-email-eric.saint.etienne@oracle.com>

On Wed, Nov 28, 2018 at 08:35:34AM -0800, Eric Saint-Etienne wrote:
> When the kernel is compiled with -ffunction-sections and perf uses the
> kernel debuginfo, perf fails the very first symbol lookup and ends up with
> an hex offset inside [kernel.vmlinux]. It's due to how perf loads the maps.
> 
> Indeed only .text gets loaded by map_groups__find() into al->map.
> Consequently al->map address range encompass the whole kernel image.
> But then map__load() loads many function maps by splitting al->map,
> which reduces al->map range drastically. Very likely the target address is
> then in one of those newly created function maps, so we need to lookup the
> map again to find that new map.
> 
> I'm not sure if this issue is only specific to the kernel but at least it
> occurs withe the kernel dso, and when we're not using the kernel debuginfo,
> perf will fallback to using kallsyms and then the first lookup will work.
> 
> The split of .text section happens in dso_process_kernel_symbol() where we
> call map_groups__find_by_name() to find an existing map, but with
> -ffunction-sections and a symbol belonging to a new (function) map, such
> map doesn't exist yet so we end up creating one and adjusting existing maps
> accordingly because adjust_kernel_syms is set there.
> 
> This patch makes sure that the event address we're looking-up is indeed
> within the map we've found, otherwise we lookup another map again.
> Only one extra lookup at most is required for the proper map to be found,
> if it exists.
> 
> Signed-off-by: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>

Reviewed-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka

      reply	other threads:[~2018-11-28 16:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28 16:35 [PATCH v3] perf symbols: Cannot disassemble some routines when debuginfo present Eric Saint-Etienne
2018-11-28 16:19 ` Jiri Olsa [this message]

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=20181128161920.GD13589@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=darren.kenny@oracle.com \
    --cc=eric.saint.etienne@oracle.com \
    --cc=eric.saintetienne@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.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 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.