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.
Created attachment 11179 [details] my patch to fix this bug
Thank you for the patch. gdb patches should be sent to the gdb-patches mailing list. See the contribution checklist for more information: https://sourceware.org/gdb/wiki/ContributionChecklist
I think this problem was fixed with https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=94481b8c8f63a2a956d18ac1e6d6134c5334cb24 and https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ea39ad355eb72b296b30a66bbc81256a071e8f1e.
Thanks. I'm closing this.
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
Created attachment 13353 [details] Patch to ensure GDB obtains file name of each loaded DLL
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.
This is now fixed by commit b388567.