Hi,
(Sorry, I missed CC to LKML)
I've found a bit odd perf-buildid-cache behavior. It seems
to be as designed, but also a bit confusing.
Issue: perf-buildid-cache's --update and --remove operations
refer the current existing binary at given path. This means
if we update the old binary, it couldn't remove nor update
the buildid-cache.
Here is the example,
----
[mhiramat@localhost perf]$ ./perf buildid-cache -v --add ./perf
Adding 51d0731187917e27fd733f2f6f34777cddbaec0f ./perf: Ok <-- (*)
[mhiramat@localhost perf]$ rm perf
[mhiramat@localhost perf]$ make clean
[mhiramat@localhost perf]$ make
[mhiramat@localhost perf]$ ./perf buildid-cache -v --update ./perf
Updating 45a97daa65f9c58adeb34af4158a6dde747de49b ./perf: FAIL <-- (*)
./perf wasn't in the cache
[mhiramat@localhost perf]$ ./perf buildid-cache -v --remove ./perf
Removing 45a97daa65f9c58adeb34af4158a6dde747de49b ./perf: FAIL <-- (*)
./perf wasn't in the cache
----
Both --update and --remove are failed after updating local binary.
Note that (*) are verbose message, without -v we don't see that.
I know this is the designed behavior, buildid-cache manages binaries
based on its build-id, not its path. However, it seems confusing.
So, I'd like to suggest to fix --update FILE to add new binary to cache
when there is no current binary cache (this will fix the first FAIL),
and add --remove-all FILE to remove all existing buildid cache about FILE
(path-based cleanup).
What would you think about that?
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: [email protected]