Hi, If pahole -J is used on an ELF that has BTF info from clang, it produces an invalid output. This is because pahole rewrites the .BTF section (which includes a new string table) but it doesn't touch .BTF.ext at all. To demonstrate, on a recent check out of bpf-next: $ cp connect4_prog.o connect4_pahole.o $ pahole -J connect4_pahole.o $ llvm-objcopy-10 --dump-section .BTF=pahole-btf.bin --dump-section .BTF.ext=pahole-btf-ext.bin connect4_pahole.o $ llvm-objcopy-10 --dump-section .BTF=btf.bin --dump-section .BTF.ext=btf-ext.bin connect4_prog.o $ sha1sum *.bin 1b5c7407dd9fd13f969931d32f6b864849e66a68 btf.bin 4c43efcc86d3cd908ddc77c15fc4a35af38d842b btf-ext.bin 2a60767a3a037de66a8d963110601769fa0f198e pahole-btf.bin 4c43efcc86d3cd908ddc77c15fc4a35af38d842b pahole-btf-ext.bin This problem crops up when compiling old kernels like 4.19 which have an extra pahole build step with clang-10. I think a possible fix is to strip .BTF.ext if .BTF is rewritten. Best Lorenz -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com