PERF-BUILDID-CACHE(1)

πŸ’… PERF-BUILDID-CACHE(1) πŸ’…

ok so this is a page from the perf Manual bestie, and it's all about the build-id cache. buckle up ✨


🌸 NAME 🌸

perf-buildid-cache β€” literally the manager of the build-id cache. that's the whole vibe. πŸŽ€


πŸ¦‹ SYNOPSIS πŸ¦‹

perf buildid-cache <options>

✨ DESCRIPTION ✨

okay so this command handles the build-id cache, and it's giving main character energy fr fr. it can add, remove, update and purge files to/from the cache. and in the future it should also set upper limits for the space used by the cache, etc. (future plans, bestie, not yet πŸ’€).

it ALSO scans the target binary for SDT (Statically Defined Tracing) and records it along with the buildid-cache, which will be used by perf-probe. for more details, see perf-probe(1). iykyk πŸ‘‘


πŸŽ€ OPTIONS πŸŽ€

  • -a, --add= β€” add the specified file to the cache. yes queen, put it in there πŸ’–
  • -f, --force β€” don't complain, just do it. no thoughts, head empty, execute 😌
  • -k, --kcore β€” add the specified kcore file to the cache. for the current host that's /proc/kcore, which requires root permissions to read πŸ”. be aware that running perf buildid-cache as root may update root's build-id cache, not the user's β€” use the -v option to see where the file is created. also note that the copied file contains only code sections, not the whole core image. and note also that files "kallsyms" and "modules" must also be in the same directory and are also copied. all 3 files are created with read permissions for root only. kcore will not be added if there's already a kcore in the cache (with the same build-id) that has the same modules at the same addresses. use the -v option to see if a copy of kcore is actually made πŸ‘€
  • -r, --remove= β€” remove a cached binary which has the same build-id as the specified file, from the cache. bye bestie πŸ‘‹
  • -p, --purge= β€” purge all cached binaries including older caches which have the specified path, from the cache. deep clean vibes 🧹
  • -P, --purge-all β€” purge ALL cached binaries. this will flush out the entire cache. like, the whole thing. no survivors πŸ’€πŸ”₯
  • -M, --missing= β€” list missing build ids in the cache for the specified file. where'd they go 😭
  • -u, --update= β€” update the specified file of the cache. note that this doesn't remove older entries, since those may still be needed for annotating old (or remote) perf.data. only if there's already a cache which has exactly the same build-id does it get replaced by the new one. it can be used to update kallsyms and kernel dso to vmlinux in order to support annotation 🫢
  • -l, --list β€” list all valid binaries from the cache. show me the receipts πŸ“‹
  • -v, --verbose β€” be more verbose. talk to me, tell me everything πŸ—£οΈ
  • --target-ns=PID β€” obtain mount namespace information from the target pid. this is used when creating a uprobe for a process that resides in a different mount namespace from the perf(1) utility. different namespace, same energy 🌈
  • --debuginfod[=URLs] β€” specify the debuginfod URL to be used when retrieving perf.data binaries. it follows the same syntax as the DEBUGINFOD_URLS variable, like:
buildid-cache.debuginfod=http://192.168.122.174:8002

if the URLs is not specified, the value of the DEBUGINFOD_URLS system environment variable is used. ✨


πŸ’œ SEE ALSO πŸ’œ

perf-record(1), perf-report(1), perf-buildid-list(1)

go read those too bestie, they're iconic 🫢


ok that's the whole page!! no notes, ate and left no crumbs πŸ“

this lil masterpiece is from the perf fam, dated 10/31/2026 β€” catch you in the next manpage, mwah πŸ’…πŸ’–

πŸ“¦ where this page comes from