perf tools: Allow build-id with trailing zeros
stable inclusion from stable-5.10.69 commit 38ab04186fb3f3b50f33e5cfde38066c5227e89d bugzilla: 182675 https://gitee.com/openeuler/kernel/issues/I4I3ED Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=38ab04186fb3f3b50f33e5cfde38066c5227e89d -------------------------------- commit 4a86d414 upstream. Currently perf saves a build-id with size but old versions assumes the size of 20. In case the build-id is less than 20 (like for MD5), it'd fill the rest with 0s. I saw a problem when old version of perf record saved a binary in the build-id cache and new version of perf reads the data. The symbols should be read from the build-id cache (as the path no longer has the same binary) but it failed due to mismatch in the build-id. symsrc__init: build id mismatch for /home/namhyung/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf. The build-id event in the data has 20 byte build-ids, but it saw a different size (16) when it reads the build-id of the elf file in the build-id cache. $ readelf -n ~/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000010 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 53e4c2f42a4c61a2d632d92a72afa08f Let's fix this by allowing trailing zeros if the size is different. Fixes: 39be8d01 ("perf tools: Pass build_id object to dso__build_id_equal()") Signed-off-by:Namhyung Kim <namhyung@kernel.org> Acked-by:
Jiri Olsa <jolsa@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20210910224630.1084877-1-namhyung@kernel.org Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Chen Jun <chenjun102@huawei.com> Acked-by:
Weilong Chen <chenweilong@huawei.com> Signed-off-by:
Chen Jun <chenjun102@huawei.com> Signed-off-by:
Zheng Zengkai <zhengzengkai@huawei.com>
Loading
Please sign in to comment