Subtle problems with "info sharedlibrary" on MS-Windows

[Eli Zaretskii]

> From: ssbssa@yahoo.de (Hannes Domani)
> Date: Wed, 10 Mar 2021 17:35:02 +0000 (UTC)
> 
>  Am Mittwoch, 10. März 2021, 17:51:43 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
> 
> > > Date: Wed, 10 Mar 2021 16:30:30 +0000 (UTC)
> > > From: Hannes Domani <ssbssa@yahoo.de>
> > >
> > > > . Some DLLs loaded explicitly via LoadLibrary don't show.? I stepped
> > > > through the code which loads them and verified they load
> > > > successfully; moreover, Process Explorer does show them loaded.
> > > > But they are nowhere to be seem in "info sharedlibrary"s display.
> > > >
> > > > . The "From" address shown by "info sharedlibrary" is different from
> > > > the base address at which the DLL is loaded: it is 4KB higher than
> > > > the base address.
> > > >
> > > > Are these problems known? I searched Bugzilla, but didn't find
> > > > anything pertinent.
> > >
> [...]
> > For the first problem, I don't have an easy reproducer. The only
> > situation where I saw it was in the native-comp branch of GNU Emacs,
> > which uses libgccjit to compile Lisp files into DLLs, then loads them
> > at run time. If you can build that branch of Emacs, I can tell you
> > how to reproduce the first problem using that build. However, maybe
> > you could see it also in other executables, if you carefully compare
> > what GDB reports against Process Explorer.
> 
> Building Emacs is a bit too much for me right now, but I will see if I notice
> it when I debug some other programs.

I found an old bug report in Bugzilla:

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

That bug describes the same problem and provides a patch.  The bug was
closed without applying the because the problem was deemed resolved by
the addition of windows_add_all_dlls function to windows-nat.c.

However, AFAIU windows_add_all_dlls solves the problem only for DLLs
loaded at startup of the debuggee.  It cannot solve the problem of
DLLs loaded dynamically by the debuggee at run time.  Which is what
happens in Emacs built with native-compilation capability: it compiles
Lisp into shared libraries, and loads those shared libraries as
needed.

The problem clearly shows itself if you enable debugevents: GDB
reports some of the LOAD_DLL_DEBUG_EVENT's without announcing the name
of the loaded DLL.  Later you can see that the DLL is not in the list
shown by "info shared", although Process Explorer shows that DLL as
being loaded by the debuggee.

So I've reopened that bug, and I hope the patch there can be applied
to GDB some time soon.

Thanks.