From: James Bottomley <James.Bottomley@suse.de>
To: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
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>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] x86: record relocation offset
Date: Wed, 30 Dec 2009 16:22:56 -0600 [thread overview]
Message-ID: <1262211776.2749.249.camel@mulgrave.site> (raw)
In-Reply-To: <20091230215847.GB2384@ghostprotocols.net>
On Wed, 2009-12-30 at 19:58 -0200, Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 30, 2009 at 06:39:36PM -0200, Arnaldo Carvalho de Melo escreveu:
> > Em Wed, Dec 30, 2009 at 11:45:30AM -0800, H. Peter Anvin escreveu:
> > > 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.
> >
> > 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?
>
> Well, I guess we could do the _stext trick again, storing its value,
> taken from /proc/kallsyms, into the perf.data header, then figuring out
> the relocation by looking at its value in the vmlinux symtab.
So reading the thread, I think the problem only exists for x86 compiled
as a relocateable kernel.
> There were concerns in the past about relying on _stext, IIRC, James?
Well, the original concerns were that _text relative relocation
resolution only works for the core kernel, not for modules.
Additionally, the kernel is in several sections, most notably init and
runtime ... these may get loaded at different locations so _text
relative symbol resolution won't work in init sections.
Right at the moment, only x86 and ppc do a relocatable kernel, and, as I
understand the process, the whole kernel image gets a relative offset
applied, so all sections get the same offset. Thus, for this case it
looks like computing the offset from any known symbol would work
(including _text).
James
next prev parent reply other threads:[~2009-12-30 22:23 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
2009-12-30 21:58 ` Arnaldo Carvalho de Melo
2009-12-30 22:22 ` James Bottomley [this message]
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
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=1262211776.2749.249.camel@mulgrave.site \
--to=james.bottomley@suse.de \
--cc=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
all inboxes | Powered by JetHome®