| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 18 May 2010 23:21:09 -0500 From: Tom Zanussi <tzanussi@...il.com> To: Stephane Eranian <eranian@...gle.com> Cc: linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu, paulus@...ba.org, davem@...emloft.net, fweisbec@...il.com, acme@...radead.org, perfmon2-devel@...ts.sf.net, eranian@...il.com, Masami Hiramatsu <mhiramat@...hat.com>, acme@...stprotocols.net Subject: Re: [BUG] perf: record does not seem to store buildids anymore Hi, On Tue, 2010-05-18 at 11:36 +0200, Stephane Eranian wrote: > Hi, > > I am trying to understand how perf record deals with buildids. > I am interested in offline and not live processing. According > to http://lkml.org/lkml/2010/5/1/5, the inject patch does not > change perf record. It should still save the buildids at the > end of the perf.data file. I suspect it does not anymore. > > If I do: > > $ perf record -o - noploop 2 | perf inject -b | perf report -v -i - > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.063 MB - (~2756 samples) ] > build id event received for > /lib/modules/2.6.34-tip-default+/build/vmlinux: > 0ad6b5dd1295e0177be9d12acafa72daac664ee7 > Looking at the vmlinux_path (5 entries long) > Using /lib/modules/2.6.34-tip-default+/build/vmlinux for symbols > build id event received for /usr/local/bin/noploop: > e8a36c0c1e36e18522233ff2a4b1fff0f9689b1c > > There is indeed a buildid generated for my noploop test program. > > But I do the simpler: > > $ perf record -o perf.out noploop 2 > noploop for 2 seconds > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.063 MB perf.out (~2739 samples) ] > > $ perf buildid-list -i perf.out > $ > > I get nothing. > > If I try with perf report -D: > > $ perf report -D -i perf.out > ..... > TOTAL events: 2011 > MMAP events: 21 > LOST events: 0 > COMM events: 1 > EXIT events: 1 > THROTTLE events: 0 > UNTHROTTLE events: 0 > FORK events: 0 > READ events: 0 > SAMPLE events: 1988 > ATTR events: 0 > EVENT_TYPE events: 0 > TRACING_DATA events: 0 > BUILD_ID events: 0 > > It shows no buildid events found. > > So either something is broken or I don't understand the logic here. Neither the live-mode nor inject patches should have changed how offline processing happens - that case still uses the original perf header write path. I think the introduction of the 'machines' abstraction may have broken build ids - looking for instance at perf_header__adds_write(), the HEADER_BUILD_ID feature is set when dsos__read_build_ids() returns true, but the session->machines loop that reads the build_ids doesn't seem to have the host machine in it, so doesn't find any buildids for the host, and therefore doesn't set the feature or later write the buildid table. I was able to get the buildids written by adding the host_machine to the loop in dsos__read_build_ids() and dsos__write_buildid_table() and was able to see them using 'perf buildid-list' by also adding host_machine to perf_session__fprintf_dsos_buildid(). I'm guessing this isn't the right way to fix it, as the code that deals with the buildids seems to assume that the host_machine is also in the session->machines list, so I'll have to look into it some more myself before sending a patch, unless someone beats me to it ;-) Tom -- 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