]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Introduce gdb_bfd_canonicalize_symtab
authorTom Tromey <tromey@adacore.com>
Thu, 6 Mar 2025 17:59:41 +0000 (10:59 -0700)
committerTom Tromey <tromey@adacore.com>
Mon, 24 Mar 2025 15:47:28 +0000 (09:47 -0600)
commit89e59ca6dce9bc7ca88b5d6c1a073c39b8f9bcc9
treec6ccbeba11b3ad8a2056c9a8c4b85737d503cbb4
parent15bbe2b14ca5b15a6e7c5c30c554fb8fd2f83e61
Introduce gdb_bfd_canonicalize_symtab

bfd_canonicalize_symtab stores the symbols in the BFD, and returns
pointers to these.  The ELF reader does not reuse these stored
symbols, so each call to bfd_canonicalize_symtab causes an allocation.

This interacts poorly with code like arm_pikeos_osabi_sniffer, which
searches the BFD symbol when called.

PR gdb/32758 points out a particularly pathological case: using "maint
info sections" on a program with a large number of sections (10000)
will cause 10000 calls to arm_pikeos_osabi_sniffer, allocating 20G.

I'm not sure BFD always worked this way.  And, fixing BFD was an
option.  However it seemed maybe better for GDB to adapt, since
adapting would mean that the fix would apply to all BFD back ends, and
not just ELF.

To that end, this patch adds a new gdb_bfd_canonicalize_symtab and
changes all callers of bfd_canonicalize_symtab to use it instead.
This new function caches the result in the per-BFD object.

I looked into having this return a view of "const asymbol *".  However
both the compile module and machoread modify the returned symbols.
And while I think this is wrong, I haven't tried to fix this here.

Regression tested on x86-64 Fedora 40.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758
gdb/arm-pikeos-tdep.c
gdb/compile/compile-object-load.c
gdb/dicos-tdep.c
gdb/elfread.c
gdb/gdb_bfd.c
gdb/gdb_bfd.h
gdb/solib-darwin.c
gdb/solib.c