On Tue, Aug 1, 2023 at 9:42 AM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > On Fri, Jul 28, 2023 at 4:34 AM Will Deacon <will@xxxxxxxxxx> wrote: > > > > Some symbols emitted in the readelf output but filtered from System.map > > 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 > > Sami, > Should we change the llvm-ir linkage type for these symbols from > `internal` to `private`? > https://llvm.org/docs/LangRef.html#linkage-types > > Then they would not appear in the symbol table. > > At first, I thought other modules might need to directly reference > this data, but with the local binding, I don't think they can. For arm64, we don't explicitly emit symbols for type prefixes (see AsmPrinter::emitKCFITypeId). These mapping symbols are emitted by AArch64ELFStreamer to mark data and code regions. According to the AArch64 ELF specification, "All mapping symbols have type STT_NOTYPE and binding STB_LOCAL," so I assume changing the linkage type isn't an option: https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#mapping-symbols Sami
