Messages in this thread | | | Date | Thu, 29 Oct 2009 13:10:15 -0200 | From | Arnaldo Carvalho de Melo <> | 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
| |