Em Thu, Jan 30, 2014 at 11:34:38AM +0200, Adrian Hunter escreveu: > On 29/01/14 21:14, Arnaldo Carvalho de Melo wrote: > > Em Wed, Jan 29, 2014 at 04:14:44PM +0200, Adrian Hunter escreveu: > >> perf buildid-cache does not make another > >> copy of kcore if the buildid and modules > >> match an existing copy. That does not
> > Humm, what is the problem? Having the ref reloc symbol we can fix things > > up, no? I.e. just using map->reloc the old kcore copy should be ok to > > use, no need to replace the kcore copy in the cache. Or am I missing > > something? > The current implementation works on the basis that kcore matches the > perf data recorded. This is just a fix for that. > I am afraid it is that way because it meets my needs. > I did not think of allowing for relocation because I need to be able > to walk the code. Relocation was one of the things I was trying to > avoid. > For me making a copy of kcore is far superior because it can be made > to have the jump labels mostly the right way around too. e.g. run a > dummy perf record while making the copy. Yes, it is superior, no question about it, I'm just trying to figure out how this fits into the build-id cache thing, i.e. it should have files keyed by its build-id, that are inserted, but not replaced, since it expects its contents to be constant. So you have a need to get the matching kcore at the time you did the record, because we're dealing with self modifying code, the kernel (soon if not already, userspace as well)... So at least we need to make this abundantly clear to users, that what is in the build-id cache may be the latest snapshot of some DSO that had a build-id at, well, build time. We need to add support for looking up in the binary where are places that are modifiable and then mark those in the UI using some visual cue. Till then, at least a paragraph in the documentation stating what happens is needed, I'll look into it. And then right now this is just for kcore, that is clearly marked as such in the build-id cache, IIRC it is in a separate directory, etc, right? - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
