Fix handling DLL loads at run time
authorEli Zaretskii <eliz@gnu.org>
Sat, 10 Apr 2021 08:33:08 +0000 (11:33 +0300)
committerEli Zaretskii <eliz@gnu.org>
Sat, 10 Apr 2021 08:42:54 +0000 (11:42 +0300)
commitb3885679dd71bed069e7e6fc2ae8b9eb05f90d62
treee60abdb20d8719e937151f481882d2bcacacc978
parentac4d7c7bfa59e47d0bcb58031c15d888158a4dfa
Fix handling DLL loads at run time

This patch makes handling a DLL load at run time (using LoadLibrary)
much more reliable when its file name cannot be obtained using the
lpImageName pointer provided by the DLL load debug event.  The
solution is to enumerate all the DLLs loaded by the inferior, looking
for the DLL that's loaded at base address provided by the lpBaseOfDll
pointer of the debug event.  Correctly resolving the DLL file name is
important, because without that GDB doesn't record the DLL in the list
of solibs, and then later is unable to show functions in that DLL in
the backtraces, which produces corrupted and truncated backtraces.
See this thread for the problems that causes:

  https://sourceware.org/pipermail/gdb-patches/2021-March/177022.html

gdb/ChangeLog:

2021-04-10  Eli Zaretskii  <eliz@gnu.org>

* windows-nat.c (windows_nat::handle_load_dll): Call
windows_add_dll if get_image_name failed to glean the name of the
DLL by using the lpImageName pointer.
(windows_add_all_dlls): Now a thin wrapper around windows_add_dll.
(windows_add_dll): Now does what windows_add_all_dlls did before,
but also accepts an argument LOAD_ADDR, which, if non-NULL,
specifies the address where the DLL was loaded into the inferior,
and looks for the single DLL loaded at that address.
gdb/ChangeLog
gdb/windows-nat.c