gdb/solib-rocm: Detect SO for unsupported AMDGPU device
authorLancelot SIX <lancelot.six@amd.com>
Wed, 26 Jul 2023 10:30:56 +0000 (11:30 +0100)
committerLancelot Six <lancelot.six@amd.com>
Thu, 24 Aug 2023 19:33:04 +0000 (19:33 +0000)
commit540a5904eb5644056f4fcc9a264826e0e40ee385
tree2e896bc8efaba46c486b4756ba521aeed75061fe
parent1f08d324601ef7fd4cce3cff8f8db4a774791828
gdb/solib-rocm: Detect SO for unsupported AMDGPU device

It is possible to debug a process which uses unsupported AMDGPU devices.
In such scenario, we can still use librocm-dbgapi.so to attach to the
process and complete the runtime activation sequence.

However, when listing shared objects loaded on the AMDGPU devices, we
might list SOs loaded on the unsupported devices.  If such SO is
seen, one of two things can happen.

First, if the arch of this device is unknown to BFD,
'gdbarch_find_by_info (gdbarch_info info)' will return the gdbarch
matching default_bfd_arch.  As a result,
rocm_solib_relocate_section_addresses will delegate the relocation
operation to svr4_so_ops.relocate_section_addresses, but this makes no
sense: this code object was not loaded by the system loader.

The second case is if BFD knows the micro-architecture of the device,
but dbgapi does not support it.  In such case, gdbarch_info_fill will
successfully identify an amdgcn architecture (bfd_arch_amdgcn).  From
there, gdbarch_find_by_info calls amdgpu_gdbarch_init which will fail to
query arch specific details from dbgapi and subsequently fail to
initialize the gdbarch object.  As a result, gdbarch_find_by_info
returns nullptr, which will down the line cause some "gdb_assert
(gdbarch != nullptr)" assertion failures.

This patch proposes to add a check in rocm_solib_bfd_open to ensure that
the architecture associated with the code object to open is fully
supported by both BFD and amd-dbgapi, and error-out otherwise.

Change-Id: Ica97ab7cba45e4944b77d3080c54c1038aaeda54
Approved-By: Pedro Alves <pedro@palves.net>
gdb/solib-rocm.c