perf: record does not seem to store buildids anymore
in [Kernel]
|
Prev: linux-next: build failure after merge of the mfd tree
Next: [BUGFIX] kprobes: Fix selftest to clear flags field for reusing probes
From: Tom Zanussi on 19 May 2010 00:30 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on 19 May 2010 08:10
Em Tue, May 18, 2010 at 11:21:09PM -0500, Tom Zanussi escreveu: > 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 ;-) Well spotted, I introduced this bug when moving the host machine out of the list of machines so that we didn't had to lookup it everytime we needed it. If you don't send it before I have breakfast I'll fix it :-) - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |