From: Ingo Molnar <mingo@elte.hu>
To: Roland McGrath <roland@redhat.com>
Cc: "Masami Hiramatsu" <mhiramat@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@redhat.com>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
lkml <linux-kernel@vger.kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Jim Keniston" <jkenisto@us.ibm.com>,
"Ananth N Mavinakayanahalli" <ananth@in.ibm.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Frank Ch. Eigler" <fche@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Jason Baron" <jbaron@redhat.com>,
"K.Prasad" <prasad@linux.vnet.ibm.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Srikar Dronamraju" <srikar@linux.vnet.ibm.com>,
systemtap <systemtap@sources.redhat.com>,
DLE <dle-develop@lists.sourceforge.net>
Subject: Re: [PATCH -tip perf/probes 00/10] x86 insn decoder bugfixes
Date: Tue, 03 Nov 2009 07:25:00 -0000 [thread overview]
Message-ID: <20091103072439.GA19928@elte.hu> (raw)
In-Reply-To: <20091029191801.CADC3538@magilla.sf.frob.com>
* Roland McGrath <roland@redhat.com> wrote:
> > Thirdly, i think we should expose the build-id of the kernel and the
> > path to the vmlinux (and modules) via /proc/build-id or so. That way
> > tooling can find the vmlinux file and can validate that it matches
> > the kernel's signature. (maybe include a file date as well - that's
> > a faster check than a full build-id checksum, especially for large
> > kernels)
>
> You seem to be confused about what build IDs are. There is no
> "checksum validation". Once the bits are stored there is no
> calculation ever done again, only exact comparison with an expected
> build ID bitstring. The size of an object file is immaterial.
>
> As Frank mentioned, the kernel's and modules' allocated ELF notes (and
> thus build IDs) are already exposed in /sys. Tools like "eu-unstrip
> -nk" use this information today.
Ah, i didnt realize we link with --build-id already, unconditonally,
since v2.6.23 (if ld supports it):
|
| From 18991197b4b588255ccabf472ebc84db7b66a19c Mon Sep 17 00:00:00 2001
| From: Roland McGrath <roland@redhat.com>
| Date: Thu, 19 Jul 2007 01:48:40 -0700
| Subject: [PATCH] Use --build-id ld option
|
| This change passes the --build-id when linking the kernel and when
| linking modules, if ld supports it. This is a new GNU ld option that
| synthesizes an ELF note section inside the read-only data. The note in
| this section contains unique identifying bits called the "build ID",
| which are generated so as to be different for any two linked ELF files
| that aren't identical.
|
So we have an SHA1 build-id already on the vmlinux and on modules, and
it's exposed in /sys/*/*/notes. Just have to make use of it in
tools/perf too.
The other useful addition i mentioned isnt implemented yet: to emit an
ELF note of the absolute path of the output directory the kernel was
built in as well. This information is not available right now, and it
would be a place to look in to search for the vmlinux and the modules.
What do you think? Also, if we do this, is there a standard way to name
it , or should i just pick a suitably new, Linux-specific name for that?
Thanks,
Ingo
next prev parent reply other threads:[~2009-11-03 7:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-27 20:42 Masami Hiramatsu
2009-10-27 20:42 ` [PATCH -tip perf/probes 06/10] kprobe-tracer: Compare both of event-name and event-group to find probe Masami Hiramatsu
2009-10-27 20:42 ` [PATCH -tip perf/probes 03/10] x86: Add pclmulq to x86 opcode map Masami Hiramatsu
2009-10-27 20:42 ` [PATCH -tip perf/probes 01/10] x86: Fix SSE opcode map bug Masami Hiramatsu
2009-10-27 20:42 ` [PATCH -tip perf/probes 04/10] x86: AVX instruction set decoder support Masami Hiramatsu
2009-10-27 20:42 ` [PATCH -tip perf/probes 05/10] x86: Add Intel FMA instructions to x86 opcode map Masami Hiramatsu
2009-10-27 20:42 ` [PATCH -tip perf/probes 02/10] x86: Merge INAT_REXPFX into INAT_PFX_* Masami Hiramatsu
2009-10-27 20:43 ` [PATCH -tip perf/probes 10/10] perf/probes: Support function entry relative line number Masami Hiramatsu
2009-10-27 20:43 ` [PATCH -tip perf/probes 08/10] perf/probes: Change command-line option of perf-probe Masami Hiramatsu
2009-10-27 20:43 ` [PATCH -tip perf/probes 09/10] perf/probes: Change probepoint syntax " Masami Hiramatsu
2009-10-27 20:43 ` [PATCH -tip perf/probes 07/10] perf/probes: Exit searching after finding target function Masami Hiramatsu
2009-10-29 8:54 ` [PATCH -tip perf/probes 00/10] x86 insn decoder bugfixes Ingo Molnar
2009-10-29 15:10 ` Arnaldo Carvalho de Melo
2009-10-29 16:56 ` Masami Hiramatsu
2009-10-29 20:10 ` Masami Hiramatsu
2009-10-29 20:25 ` Josh Stone
2009-10-29 20:41 ` Masami Hiramatsu
2009-11-02 21:16 ` [PATCH -tip perf/probes 00/10] x86 insn decoder bugfixes and perf-probe syntax changes Masami Hiramatsu
2009-11-02 21:26 ` Frederic Weisbecker
2009-11-02 21:57 ` Masami Hiramatsu
2009-11-03 0:37 ` Masami Hiramatsu
2009-11-03 7:33 ` Ingo Molnar
2009-11-03 15:07 ` Masami Hiramatsu
2009-10-29 17:16 ` [PATCH -tip perf/probes 00/10] x86 insn decoder bugfixes Frank Ch. Eigler
2009-10-29 19:18 ` Roland McGrath
2009-11-03 7:25 ` Ingo Molnar [this message]
2009-11-03 12:35 ` Using build-ids in perf tools was " Arnaldo Carvalho de Melo
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=20091103072439.GA19928@elte.hu \
--to=mingo@elte.hu \
--cc=acme@redhat.com \
--cc=ananth@in.ibm.com \
--cc=dle-develop@lists.sourceforge.net \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jbaron@redhat.com \
--cc=jkenisto@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=peterz@infradead.org \
--cc=prasad@linux.vnet.ibm.com \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=systemtap@sources.redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).