On Tue, Jan 21, 2025 at 6:29 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
>
> From: Arnd Bergmann <arnd@xxxxxxxx>
>
> I noticed a regression in the time it takes to fully link some randconfig
> kernels and bisected this to commit 0043ecea2399 ("vmlinux.lds.h: Adjust
> symbol ordering in text output section"), which (among other changes) moves
> .text.unlikely ahead of .text.
>
> Partially reverting this makes the final link over six times faster again,
> back to what it was in linux-6.12:
>
> linux-6.12 linux-6.13
> ld.lld v20 1.2s 1.2s
> ld.bfd v2.36 3.2s 5.2s
> ld.bfd v2.39 59s 388s
>
> According to the commit description, that revert is not allowed here
> because with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, the .text.unlikely
> section name conflicts with the function-section names. On the other
> hand, the excessive link time happens both with and without that
> option, so the order could be conditional.
>
> I did not try to bisect the linker beyond trying multiple versions
> I had installed already, and it does feel like the behavior of recent
> versions (tested 2.39 and 2.42 with identical results) is broken in
> some form that earlier versions were not. According to 'perf', most
> of the time is spent in elf_link_adjust_relocs() and ext64l_r_offset().
Is this problem specific to the BFD linker from binutils?
Did you observe a link speed regression with LLVM=1 build?
--
Best Regards
Masahiro Yamada
