[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100519120747.GF14367@ghostprotocols.net>
Date: Wed, 19 May 2010 09:07:48 -0300
From: Arnaldo Carvalho de Melo <acme@...radead.org>
To: Tom Zanussi <tzanussi@...il.com>
Cc: Stephane Eranian <eranian@...gle.com>,
linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu,
paulus@...ba.org, davem@...emloft.net, fweisbec@...il.com,
perfmon2-devel@...ts.sf.net, eranian@...il.com,
Masami Hiramatsu <mhiramat@...hat.com>
Subject: Re: [BUG] perf: record does not seem to store buildids anymore
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@...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