Re: [PATCH 1/2] scripts/faddr2line: Ignore non-function symbols in readelf output

From: Josh Poimboeuf
Date: Mon Jul 24 2023 - 19:47:42 EST


On Mon, Jul 24, 2023 at 06:45:16PM +0100, Will Deacon wrote:
> Non-function symbols emitted in the readelf output can confuse the
> 'faddr2line' symbol size calculation, resulting in the erroneous
> rejection of valid offsets. This is especially prevalent when building
> an arm64 kernel with CONFIG_CFI_CLANG=y, where most functions are
> prefixed with a 32-bit data value in a '$d.n' section. For example:
>
> 447538: ffff800080014b80 548 FUNC GLOBAL DEFAULT 2 do_one_initcall
> 104: ffff800080014c74 0 NOTYPE LOCAL DEFAULT 2 $x.73
> 106: ffff800080014d30 0 NOTYPE LOCAL DEFAULT 2 $x.75
> 111: ffff800080014da4 0 NOTYPE LOCAL DEFAULT 2 $d.78
> 112: ffff800080014da8 0 NOTYPE LOCAL DEFAULT 2 $x.79
> 36: ffff800080014de0 200 FUNC LOCAL DEFAULT 2 run_init_process
>
> Adding a warning to do_one_initcall() results in:
>
> | WARNING: CPU: 0 PID: 1 at init/main.c:1236 do_one_initcall+0xf4/0x260
>
> Which 'faddr2line' refuses to accept:
>
> $ ./scripts/faddr2line vmlinux do_one_initcall+0xf4/0x260
> skipping do_one_initcall address at 0xffff800080014c74 due to size mismatch (0x260 != 0x224)
> no match for do_one_initcall+0xf4/0x260
>
> Filter out entries from readelf that are not "FUNC" type, so that the
> size of a symbol is calculated as a delta to the next function address.

Problem is, I think the kernel's symbol printing code prints the nearest
kallsyms symbol, and there are some valid non-FUNC code symbols. For
example, syscall_return_via_sysret. This patch would cause those valid
symbols to get missed.

I presume these '$x.*' symbols don't end up in System.map? How do they
get filtered out? By the linker maybe?

We may want to use whatever criteria used there, e.g. have faddr2line
ignore symbols starting with '$' or so?

--
Josh