On 19/11/2024 22:04, Eduard Zingerman wrote: > On Tue, 2024-11-19 at 10:40 -0300, Arnaldo Carvalho de Melo wrote: > > [...] > > I tried the following test on top of this patch-set: > > ----- 8< ---------------------------------------- > #!/bin/bash > > cat <<EOF | clang -o btf-and-dwarf.o -c -x c -g - || exit 1 > struct test_val { int i; } g; > EOF > pahole --btf_encode btf-and-dwarf.o || exit 1 > # Note: has to be llvm-strip, otherwise --no-strip-all is not available > llvm-strip -o only-dwarf.o --no-strip-all -R .BTF -R .BTF.ext btf-and-dwarf.o > llvm-strip -o only-btf.o --no-strip-all --strip-debug btf-and-dwarf.o > > for fmt in none btf dwarf dwarf,btf; do > for file in no-such-file only-btf.o only-dwarf.o btf-and-dwarf.o; do > if [ "$fmt" == "none" ]; then > cmd="pahole" > else > cmd="pahole -F ${fmt}" > fi > printf -- "------ PAHOLE_VMLINUX_BTF_FILENAME=%-20s %-20s ------\n" "${file}" "${cmd}" > PAHOLE_VMLINUX_BTF_FILENAME=$file $cmd 2>&1 | grep -P '(test_val|pahole:)' > done > done this is a nice test, maybe we could adapt it for inclusion. more below.. > ---------------------------------------- >8 ----- > > And there are a few surprising (to me) results, namely: > > ------ PAHOLE_VMLINUX_BTF_FILENAME=only-dwarf.o pahole ------ > pahole: couldn't find any debug information on this system. > ... > ------ PAHOLE_VMLINUX_BTF_FILENAME=only-dwarf.o pahole -F dwarf ------ > pahole: couldn't find any debug information on this system. > ... > ------ PAHOLE_VMLINUX_BTF_FILENAME=btf-and-dwarf.o pahole -F dwarf ------ > pahole: couldn't find any debug information on this system. > ... > ------ PAHOLE_VMLINUX_BTF_FILENAME=only-dwarf.o pahole -F dwarf,btf ------ > pahole: couldn't find any debug information on this system. > ... > > It looks like DWARF is never loaded. > llvm-dwarfdump shows that DWARF is indeed present in only-dwarf.o and > btf-and-dwarf.o. Is this an expected behaviour? > > So my read of the current intent is for PAHOLE_VMLINUX_BTF_FILENAME to provide an override path for BTF debug info only. In the above cases we know where to find BTF but don't go on to assume there is DWARF there too. I think this behaviour would be more surprising if the variable was called something more generic like PAHOLE_VMLINUX_DEBUGINFO_FILENAME - i.e. not specific to debug info type - but that's just my take. We could certainly make the override mechanism more generic to other debuginfo types, but I think that could be done in follow-ups. What do you think? Thanks! Alan