[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091029151014.GA7266@ghostprotocols.net>
Date: Thu, 29 Oct 2009 13:10:15 -0200
From: Arnaldo Carvalho de Melo <acme@...radead.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Masami Hiramatsu <mhiramat@...hat.com>,
Frédéric Weisbecker <fweisbec@...il.com>,
lkml <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Jim Keniston <jkenisto@...ibm.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Christoph Hellwig <hch@...radead.org>,
"Frank Ch. Eigler" <fche@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Jason Baron <jbaron@...hat.com>,
"K.Prasad" <prasad@...ux.vnet.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
systemtap <systemtap@...rces.redhat.com>,
DLE <dle-develop@...ts.sourceforge.net>
Subject: Re: [PATCH -tip perf/probes 00/10] x86 insn decoder bugfixes
Em Thu, Oct 29, 2009 at 09:53:48AM +0100, Ingo Molnar escreveu:
> 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)
Yeah, build-id need to be a first class citizen, being always available for
checking that the DSO in disk matches the one being currently used by some app.
Right now I got myself staring at these messages in a perf top session:
No symbols found in /usr/lib/libvte.so.9.6.0 (deleted), maybe install a debug package?
No symbols found in /lib/libgobject-2.0.so.0.2000.5.#prelink#.MDypV3 (deleted), maybe install a debug package?
No symbols found in /usr/lib/libpixman-1.so.0.14.0 (deleted), maybe install a debug package?
No symbols found in /usr/lib/libgdk-x11-2.0.so.0.1600.6.#prelink#.4CriMV (deleted), maybe install a debug package?
No symbols found in /lib/libgthread-2.0.so.0.2000.5.#prelink#.0ooYbx (deleted), maybe install a debug package?
No symbols found in /usr/lib/libX11.so.6.2.0 (deleted), maybe install a debug package?
No symbols found in /usr/lib/libxcb.so.1.1.0 (deleted), maybe install a debug package?
Well, I did a 'yum upgrade' and there are some binaries still running that hold
reference counts to those DSOs, but there is not anymore any place I can look
for its buildid to get the right symtab.
Corner case, yeah, but it would be nice to be able to query for its buildid and
then get the right symtab.
But as we don't have that, I'll just look for (deleted) at the end of the DSO
name and emit a more friendly warning...
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists