Re: Subtle problems with "info sharedlibrary" on MS-Windows

[Eli Zaretskii via Gdb-patches <gdb-patches@sourceware.org>]

> 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.
> 
> I'm not aware of these kind of problems.
> Is there any way I can try to reproduce this?

The second one is easy: just debug any program that loads DLLs, either
because it requires them or loads them dynamically with LoadLibrary.
For example, debug gdb.exe itself, type "start", and then "info
shared".  You will see that the From address of each DLL ends in
"1000".  Now start Process Explorer and look at the Image Base or Base
address of those same DLLs: you will see it is 1000 hex (4096 decimal)
lower than what GDB shows, i.e. the image start address ends in 0000,
being 64KB aligned.

(I found this because AFAIU the handle returned by LoadLibrary is the
starting address where the DLL is loaded, and I saw the 4K mismatch
between that handle and what GDB was reporting as the starting
address.)

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.

Thanks.