public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	fche LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] x86: record relocation offset
Date: Wed, 30 Dec 2009 18:39:36 -0200	[thread overview]
Message-ID: <20091230203936.GA2384@ghostprotocols.net> (raw)
In-Reply-To: <4B3BADDA.8040102@zytor.com>

Em Wed, Dec 30, 2009 at 11:45:30AM -0800, H. Peter Anvin escreveu:
> On 12/30/2009 05:15 AM, Arnaldo Carvalho de Melo wrote:
> > I'm no expert on the intricacies of boot_params, but all the other hunks
> > seems sensible, but can't we provide a non-perf specific way of getting
> > the relocate_offset? I guess other tools would also love to have it.

> > What about systemtap, don't they solve this in some other way? Frank?
> 
> I at one point proposed that boot_params should be exported in toto via
> sysfs.  This got rather brutally shut down as "it's just a debugging
> feature" and got moved to debugfs (/debug/boot_params/data).  However,
> the entire boot_params structure is available there.
> 
> Regardless of the reporting method, the patch passing this in by
> modifying the early assembly code, though, is more than a little
> pointless.  The kernel already knows where it is loaded -- obviously, by
> sheer necessity -- and knows how it was itself configured, and as such
> we can do this calculation in C code without modifying boot_params or
> the early bootstrap.

Yeah, rereading the start of this discussion it now seems to me that
what is happening is that a valid vmlinux is found, i.e. one with the
same buildid as the buildid found in the perf.data file but then the
kernel, at the time of perf record, was relocated, not matching what is
in the vmlinux file.

So what we need to do is to figure this out at 'perf record' time and
encode this in the header, so that later, at 'perf report' time, we can
use a matching vmlinux and do the relocation (store this relocation
offset in struct map->start for the kernel map)  to get the right
results.

Problem is that at 'perf record' time we may not have access to the
vmlinux file, and thus not be able to figure out the relocation applied
in that boot.

Then, at a later time, and possibly on another machine, on another arch,
we try to map back IPs to symbols, the /proc/kallsyms is completely
unrelated and we now have a vmlinux unrelocated...

So we need a way to get the relocation applied at 'perf record' time and
encode it in the perf.data header. Ideas about how to do that?

- Arnaldo

  reply	other threads:[~2009-12-30 20:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-30  3:15 [PATCH 0/3] perf_event: fix getting symbol error if kernel is relocatable Xiao Guangrong
2009-12-30  3:16 ` [PATCH 1/3] x86: record relocation offset Xiao Guangrong
2009-12-30 13:15   ` Arnaldo Carvalho de Melo
2009-12-30 19:45     ` H. Peter Anvin
2009-12-30 20:39       ` Arnaldo Carvalho de Melo [this message]
2009-12-30 21:58         ` Arnaldo Carvalho de Melo
2009-12-30 22:22           ` James Bottomley
2009-12-30  3:17 ` [PATCH 2/3] perf_event: support getting " Xiao Guangrong
2009-12-30  3:18 ` [PATCH 3/3] perf tools: adjust symbol address Xiao Guangrong
2009-12-30 13:10   ` Arnaldo Carvalho de Melo
2009-12-31  2:59     ` Xiao Guangrong
2009-12-31 10:29       ` Arnaldo Carvalho de Melo
2009-12-31 10:49         ` Xiao Guangrong
2009-12-31 11:08           ` Arnaldo Carvalho de Melo
2009-12-31 11:30             ` Xiao Guangrong
  -- strict thread matches above, loose matches on Subject: below --
2009-12-30 22:09 [PATCH 1/3] x86: record relocation offset H. Peter Anvin
2009-12-30 23:26 H. Peter Anvin
2009-12-30 23:41 ` James Bottomley
2009-12-30 23:46   ` H. Peter Anvin
2009-12-31  0:30     ` Arnaldo Carvalho de Melo
2009-12-31  3:00       ` Xiao Guangrong
2009-12-31 10:36         ` Arnaldo Carvalho de Melo
2009-12-31 10:50           ` Xiao Guangrong
2010-01-01  9:27           ` Ingo Molnar
2009-12-31  2:58     ` Xiao Guangrong
2009-12-31  0:53   ` Frank Ch. Eigler

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=20091230203936.GA2384@ghostprotocols.net \
    --to=acme@infradead.org \
    --cc=fche@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=xiaoguangrong@cn.fujitsu.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