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

[Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>]

 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.
> >
> > 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.)

Oh, that's what you mean.
I think it always was like this, so I assumed this was intentional.
It shows the address of the .text section, not of the DLL base.


> 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.


Hannes