summaryrefslogtreecommitdiffstats
path: root/scripts/Makefile.lib
diff options
context:
space:
mode:
authorPeter Zijlstra <peterz@infradead.org>2022-10-28 20:29:51 +0200
committerPeter Zijlstra <peterz@infradead.org>2022-11-01 13:44:08 +0100
commit13f60e80e15dd0657c90bcca372ba045630ed9de (patch)
tree953847669387957ccbeb914739af7b1a222d2adb /scripts/Makefile.lib
parentobjtool: Slice up elf_create_section_symbol() (diff)
downloadlinux-13f60e80e15dd0657c90bcca372ba045630ed9de.tar.xz
linux-13f60e80e15dd0657c90bcca372ba045630ed9de.zip
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
Diffstat (limited to 'scripts/Makefile.lib')
0 files changed, 0 insertions, 0 deletions