Our (openSUSE) build of perf results in 2 binaries trace & perf (ls -li): > 43866954 -rwxr-xr-x 2 abuild abuild 16704336 zář 22 09:15 perf > 43866954 -rwxr-xr-x 2 abuild abuild 16704336 zář 22 09:15 trace They are hard links. The same holds for separated debuginfo binaries: > 43844091 -rwxr-xr-x 3 abuild abuild 28341208 zář 22 09:15 perf-5.8.7-0.x86_64.debug > 43844091 -rwxr-xr-x 3 abuild abuild 28341208 zář 22 09:15 trace-5.8.7-0.x86_64.debug Now when dwz is run: $ dwz -h -r -m .dwz/perf-5.8.7-0.x86_64 -l 10000000 -L 50000000 ./usr/bin/perf-5.8.7-0.x86_64.debug ./usr/bin/trace-5.8.7-0.x86_64.debug .... it results in (strace): > openat(AT_FDCWD, "./usr/bin/trace-5.8.7-0.x86_64.debug", O_RDONLY) = 8 > fstat(8, {st_mode=S_IFREG|0755, st_size=28341208, ...}) = 0 > getpid() = 26887 > openat(AT_FDCWD, "./usr/bin/trace-5.8.7-0.x86_64.debug.#dwz#.maMA6e", O_RDWR|O_CREAT|O_EXCL, 0600) = 9 > close(9) = 0 > unlink("./usr/bin/trace-5.8.7-0.x86_64.debug.#dwz#.maMA6e") = 0 > link("./usr/bin/perf-5.8.7-0.x86_64.debug", "./usr/bin/trace-5.8.7-0.x86_64.debug.#dwz#.maMA6e") = 0 > rename("./usr/bin/trace-5.8.7-0.x86_64.debug.#dwz#.maMA6e", "./usr/bin/trace-5.8.7-0.x86_64.debug") = 0 The thing is that the rename is thought to actually remove 'oldpath' (first argument), but in case of hardlinks, it is documented it does nothing: > If oldpath and newpath are existing hard links referring to the > same file, then rename() does nothing, and returns a success status. Sure, perf-5.8.7-0.x86_64.debug and trace-5.8.7-0.x86_64.debug are hard links and you create trace-5.8.7-0.x86_64.debug.#dwz#.maMA6e (which links to perf-*) and then rename it to trace-5.8.7-0.x86_64.debug which is still the same hard link. Should you remove newpath first? Or do not create the link if it exists already? Note that perf is special: > dwz: ./usr/bin/perf-5.8.7-0.x86_64.debug: DWARF compression not beneficial - old size 9932364 new size 9932655 So this is likely reason, why perf-5.8.7-0.x86_64.debug is left unchanged and trace -> perf hard link still exists.
I believe this is PR24275 Which has a proposed patch: https://sourceware.org/legacy-ml/dwz/2019-q1/msg00060.html But that has never been applied?
This is indeed PR24275. But the proposed patch there doesn't apply anymore to the current code. *** This bug has been marked as a duplicate of bug 24275 ***