Bug 17659 - [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event
Summary: [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-11-28 01:10 UTC by asmwarrior
Modified: 2021-04-10 08:47 UTC (History)
3 users (show)

See Also:
Last reconfirmed:

my patch to fix this bug (2.21 KB, patch)
2018-08-11 14:20 UTC, asmwarrior
Details | Diff
Patch to ensure GDB obtains file name of each loaded DLL (1.29 KB, patch)
2021-04-06 15:22 UTC, Eli Zaretskii
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description asmwarrior 2014-11-28 01:10:01 UTC
Hi, I see that some dlls are not listed when I type the "info shared" command under my Windows XP system. Thus, I can't set debug into the missing dll(such as I can't set a break point in the missing dll)

I exam the source code a little, and found that we have a function named:
static char *
get_image_name (HANDLE h, void *address, int unicode)

Which try to get the loaded dll name, but after debugged for a while, I see that for some dlls (not only the ntdll.dll, but there are other dlls), this function failed to get the image name of the dll. This is due to the condition that:

  /* See if we could read the address of a string, and that the
     address isn't null.  */
  if (!ReadProcessMemory (h, address,  &address_ptr,
			  sizeof (address_ptr), &done)
      || done != sizeof (address_ptr) || !address_ptr)
    return NULL;

Here, the address_ptr is NULL.

By looking at MSDN, I see that this value could be NULL, see: [LOAD_DLL_DEBUG_INFO structure (Windows)](http://msdn.microsoft.com/en-us/library/windows/desktop/ms680351(v=vs.85).aspx), as said by MSDN, the value lpImageName could not contains any information.

So, I think the correct way to get the dll name is to through the hFile value of the LOAD_DLL_DEBUG_INFO, I see many articles saying about this, E.g.: [Writing Windows Debugger - Part 2 - CodeProject](http://www.codeproject.com/Articles/132742/Writing-Windows-Debugger-Part), it refer to a function named: GetFileNameFromHandle(), this function can also be seen from MSDN in the page:

[Obtaining a File Name From a File Handle (Windows)](http://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx)

But to use this function, we need to include the psapi.dll under WindowsXP, which need link to libpsapi.a in MinGW. I don't tried it yet.
Comment 1 asmwarrior 2018-08-11 14:20:52 UTC
Created attachment 11179 [details]
my patch to fix this bug
Comment 2 Tom Tromey 2018-08-16 14:35:20 UTC
Thank you for the patch.

gdb patches should be sent to the gdb-patches mailing list.
See the contribution checklist for more information:

Comment 4 Tom Tromey 2020-02-03 15:48:22 UTC
Thanks.  I'm closing this.
Comment 5 Eli Zaretskii 2021-04-05 17:41:12 UTC
I'm reopening this.  The problem is not completely solved, because the changes pointed to in Comment 3 only handle the DLLs loaded at program start.  They don't handle the same problem with DLLs that are dynamically loaded by the debuggee at run time.

This is exactly what happens in Emacs with native-compilation of Lisp packages.  Each Lisp package is compiled into one or more *.eln files, each of which is a DLL in disguise.  Emacs loads each of these *.eln files when it needs it the first time.  Some of those DLLs appear to GDB with NULL or empty name as found by following the lpImageName member of the DLL debug event, and then GDB doesn't know about these DLLs, and cannot produce valid backtraces and other debug support for those DLLs.

To fix that we need either the code shown by asmwarrior, or another call to windows_add_all_dlls, either automatically upon receiving a DLL load debug event for which we are unable to glean the DLL name, or at least manually whenever a loaded DLL doesn't appear in "info shared".

See also my report of the results of this problem in

Comment 6 Eli Zaretskii 2021-04-06 15:22:51 UTC
Created attachment 13353 [details]
Patch to ensure GDB obtains file name of each loaded DLL
Comment 7 Eli Zaretskii 2021-04-06 15:24:33 UTC
The above patch is IMO a simpler way of fixing the problem than the original patch presented by asmwarrior.  It reuses code we already have in GDB for enumerating all the DLLs mapped into the inferior.
Comment 8 Eli Zaretskii 2021-04-10 08:47:40 UTC
This is now fixed by commit b388567.