`perf annotate` (and other disassemblies) do not show source code by default anymore

Description:

By default, perf's disassemblies (perf report, perf annotate...) do not interleave source code. This appears to be a regression of sorts, and can be worked around by explicitly passing the --objdump flag.

By default, since Arch builds perf with libLLVM support, that has priority over parsing objdump output, unless --objdump is passed. (My debugging stopped at determining that LLVM does correctly map the assembly lines back to source code, but I couldn't determine why they aren't printed.) I'd argue this is a usability regression, though reverting to objdump also adds some noise that could also be considered a usability regression.

Additional info:

• package version(s): perf 6.12-1, llvm-libs 18.1.8-4, binutils 2.43+r4+g7999dae6961-1
• config and/or log files: N/A
• link to upstream bug report, if any: N/A

Steps to reproduce:

1. Save the following as, say, test.c:

   int main(int argc, char *argv[]) {
   	for (;;) {
   		asm("nop");
   	}
   }

2. gcc -O0 -g test.c -o test
3. perf record ./test, and Ctrl-C soon after.
4. perf annotate, notice the lack of source code, even when pressing the s key.
5. perf annotate --objdump=$(which objdump), notice that source code is now interleaved. (Together with a lot of extra cruft, though.)

(This has been reproduced with real-world programs as well, though.)

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @toolybird, and @gromit

Thanks for reporting. I'd also argue the deps for the perf pkg are buggy:

$ perf record ./test
perf: error while loading shared libraries: libLLVM.so.18.1: cannot open shared object file: No such file or directory

But back on topic, yeah, the previous version seems to work.. so this does indeed look like a regression. Although, it was only a routine pkgver bump.. so it's quite likely an upstream change is the root cause?

libLLVM support was added in 6.12, so that would explain why the regression is caused by a simple version bump. (It works at compile time, because clang is a makedepends of perf for some reason).

The question then becomes, is the missing line info an upstream problem (in which case I suppose that it should be disabled via the appropriate make flag), or is it due to some packaging misconfiguration? I don't really know how to check that, so my debugging stopped short of it.

Please test following -3 in testing: 56d71145

libLLVM support was added in 6.12, so that would explain why the regression is caused by a simple version bump. (It works at compile time, because clang is a makedepends of perf for some reason).

Yes, It was added in 6.12. I have not catched it, because the pkgctl namecap was pretty big and this was the first time pushing the package from my side. I have tested the package locally quite much, but since I had llvm installed I have not noticed the issue.

the makedepends+=(...) applies then to the whole compilation and the reason I have not noticed it.

Thanks for the report!

added scoperegression statusconfirmed labels and removed statusunconfirmed label

assigned to @seblu and unassigned @freswa, @toolybird, and @gromit

@bugbuddy assign @ptr1337

assigned to @ptr1337

@issotm

Please also test following pkg:

sudo pacman -U https://pkgbuild.com/~ptr1337/perf-no-libllvm/perf-6.12-4-x86_64.pkg.tar.zst

Diff:

diff --git a/PKGBUILD b/PKGBUILD
index 147a6d5..eac2d6c 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -91,6 +91,7 @@ build() {
     NO_SDT=1 \
     BUILD_BPF_SKEL=1 \
     PYTHON=python \
+    NO_LIBLLVM=1 \
     PYTHON_CONFIG=python-config \
     DESTDIR="$pkgdir"
   popd
@@ -178,6 +179,7 @@ package_perf() {
     NO_SDT=1 \
     BUILD_BPF_SKEL=1 \
     PYTHON=python \
+    NO_LIBLLVM=1 \
     PYTHON_CONFIG=python-config \
     DESTDIR="$pkgdir" \
     install install-python_ext

On my side perf annotate shows the source code again.

Pacman is complaining that the .sig file 404's.

Please download it manually and then use sudo pacman -U $pkgname.

Yep, can confirm this works! (Nonetheless slightly bumming that some more noise, such as Disassembly of section .text, is back—but this is no worse than it was with 6.11, so certainly good enough.)

Thank you ^^

Great, thanks! Gonna push it soonish. May we want to report to bug upstream.

I guess the question is if the issue also occurs with an up-to date LLVM

I agree it sounds like a good idea. It also seems to me that, as a distro maintainer, you'd have more weight when interfacing with upstream; but let me know if you'd rather I do that myself.

closed with commit ffe3e0da