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

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

[Stephane Eranian]

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.

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

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

[Arnaldo Carvalho de Melo]

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