]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb/solib-rocm: avoid expensive gdbarch_from_bfd call in rocm_solib_relocate_section_...
authorSimon Marchi <simon.marchi@efficios.com>
Mon, 27 Oct 2025 19:41:51 +0000 (15:41 -0400)
committerSimon Marchi <simon.marchi@efficios.com>
Tue, 28 Oct 2025 15:55:23 +0000 (11:55 -0400)
commit338796db769342bffe41e362cb62bf2155345b2f
tree2e027bb65e35273fef18ae586a3ca5b2c95d40e9
parent20adfa53dcbd19bc3d185ed7365e3f38d42f078c
gdb/solib-rocm: avoid expensive gdbarch_from_bfd call in rocm_solib_relocate_section_addresses

Loading a library containing a lot (> 100k) sections proved very slow
with whenever the support for ROCm was built into gdb.  The culprit is
the gdbarch_from_bfd call in rocm_solib_relocate_section_addresses:

    if (!is_amdgpu_arch (gdbarch_from_bfd (so.abfd.get ())))

This function gets called for every section, and gdbarch_from_bfd is
somewhat slow.  It turns out that we can skip the gdbarch_from_bfd call,
since all is_amdgpu_arch needs is the bfd_architecture value, which we
can directly extract from the `bfd *`, without going through the
gdbarch.

Add an overload of is_amdgpu_arch that takes a `bfd *`, and use it in
rocm_solib_relocate_section_addresses.

Update a call site in rocm_solib_bfd_open to use the new overload as
well.  That call site is not as much in a hot path, but there is no
point in paying the extra cost of looking up the gdbarch there.  I
removed the other assert that checked that gdbarch_from_bfd returned a
non-nullptr value.  If that was the case, something would be very wrong
with ROCgdb, and the problem would manifest very soon after anyway.

Change-Id: I55e9e68af59903b1b9727ff57388f9469d0e0002
Approved-by: Lancelot Six <lancelot.six@amd.com> (AMDGPU)
gdb/amdgpu-tdep.c
gdb/amdgpu-tdep.h
gdb/solib-rocm.c