OSDN Git Service

objtool: Avoid O(bloody terrible) behaviour -- an ode to libelf
authorPeter Zijlstra <peterz@infradead.org>
Fri, 28 Oct 2022 18:29:51 +0000 (20:29 +0200)
committerPeter Zijlstra <peterz@infradead.org>
Tue, 1 Nov 2022 12:44:08 +0000 (13:44 +0100)
commit13f60e80e15dd0657c90bcca372ba045630ed9de
tree953847669387957ccbeb914739af7b1a222d2adb
parent4c91be8e926c6b3734d59b9348e305431484d42b
objtool: Avoid O(bloody terrible) behaviour -- an ode to libelf

Due to how gelf_update_sym*() requires an Elf_Data pointer, and how
libelf keeps Elf_Data in a linked list per section,
elf_update_symbol() ends up having to iterate this list on each
update to find the correct Elf_Data for the index'ed symbol.

By allocating one Elf_Data per new symbol, the list grows per new
symbol, giving an effective O(n^2) insertion time. This is obviously
bloody terrible.

Therefore over-allocate the Elf_Data when an extention is needed.
Except it turns out libelf disregards Elf_Scn::sh_size in favour of
the sum of Elf_Data::d_size. IOW it will happily write out all the
unused space and fill it with:

  0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND

entries (aka zeros). Which obviously violates the STB_LOCAL placement
rule, and is a general pain in the backside for not being the desired
behaviour.

Manually fix-up the Elf_Data size to avoid this problem before calling
elf_update().

This significantly improves performance when adding a significant
number of symbols.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Yujie Liu <yujie.liu@intel.com>
Link: https://lkml.kernel.org/r/20221028194453.461658986@infradead.org
tools/objtool/elf.c
tools/objtool/include/objtool/elf.h