Re: [BUG] perf: record does not seem to store buildids anymore

[Tom Zanussi]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/