Re: [PATCH 3/5] pahole: Honour exclusive BTF loading

Alan Maguire
2024-11-19T22:28:53Z

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