[Bug gdb/17659] New: [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event

[Bug gdb/17659] New: [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event

[asmwarrior at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17659

            Bug ID: 17659
           Summary: [win32] GDB failed to get dll names when handling
                    LOAD_DLL_DEBUG_EVENT event
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: asmwarrior at gmail dot com

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17659] [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event

[eliz at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17659

Eli Zaretskii <eliz at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |eliz at gnu dot org
         Resolution|FIXED                       |---

--- Comment #5 from Eli Zaretskii <eliz at gnu dot org> ---
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

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17659] [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event

[eliz at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17659

--- Comment #6 from Eli Zaretskii <eliz at gnu dot org> ---
Created attachment 13353
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13353&action=edit
Patch to ensure GDB obtains file name of each loaded DLL

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17659] [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event

[eliz at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17659

--- Comment #7 from Eli Zaretskii <eliz at gnu dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/17659] [win32] GDB failed to get dll names when handling LOAD_DLL_DEBUG_EVENT event

[eliz at gnu dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=17659

Eli Zaretskii <eliz at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Eli Zaretskii <eliz at gnu dot org> ---
This is now fixed by commit b388567.

-- 
You are receiving this mail because:
You are on the CC list for the bug.