Re: [PATCH v2] Fix WOW64 process system DLL paths

[Hannes Domani <ssbssa@yahoo.de>]

 Am Mittwoch, 25. März 2020, 15:23:44 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:

> On 2020-03-25 10:22 a.m., Hannes Domani via Gdb-patches wrote:
> >  Am Mittwoch, 25. März 2020, 15:04:44 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> >
> >> On 2020-03-24 3:23 p.m., Hannes Domani via Gdb-patches wrote:
> >>
> >>> GetModuleFileNameEx returns for some DLLs of WOW64 processes
> >>> the path inside the 64bit system directory instead of the 32bit
> >>> syswow64 directory.
> >>>
> >>> Problem happens e.g. with dbghelp.dll:
> >>>
> >>> (gdb) start
> >>> Temporary breakpoint 1 at 0x415a00: file fiber.cpp, line 430.
> >>> Starting program: C:\src\tests\fiber.exe
> >>> warning: `C:\Windows\system32\dbghelp.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
> >>>
> >>> Temporary breakpoint 1, main () at fiber.cpp:430
> >>> 430    {
> >>> (gdb) info sharedlibrary
> >>> From        To          Syms Read  Shared Object Library
> >>> 0x77070000  0x771d4d20  Yes (*)    C:\Windows\SysWOW64\ntdll.dll
> >>> 0x74dc0000  0x74ebad9c  Yes (*)    C:\Windows\syswow64\kernel32.dll
> >>> 0x75341000  0x75386a18  Yes (*)    C:\Windows\syswow64\KernelBase.dll
> >>> 0x6f6a1000  0x6f7c48fc  Yes (*)    C:\Windows\system32\dbghelp.dll
> >>> 0x74d01000  0x74dab2c4  Yes (*)    C:\Windows\syswow64\msvcrt.dll
> >>> (*): Shared library is missing debugging information.
> >>>
> >>> This detects this situation and converts the DLL path to the
> >>> syswow64 equivalent.
> >>>
> >>> gdb/ChangeLog:
> >>>
> >>> 2020-03-24  Hannes Domani  <ssbssa@yahoo.de>
> >>>
> >>>      * windows-nat.c (windows_add_all_dlls): Fix system dll paths.
> >>> ---
> >>> v2:
> >>> - added error check with gdb_assert's
> >>> - use std::string for newly assembled dll path
> >>
> >>
> >> Btw, I found this Stack Overflow question that seems to be about this exact
> >> problem (which you may have already found too if you researched the topic),
> >> but honestly I don't understand a thing from the answer.
> >>
> >>    https://stackoverflow.com/questions/46403532/getmodulefilenameex-on-32bit-process-from-64bit-process-on-windows-10
> >
> > Yes, I did see this when I googled this problem.
> > Basically, if you use GetMappedFileName instead of GetModuleFileNameEx, you
> > get the correct path (I tested this also), but it's returned in the nt-path
> > format:
> > \Device\HarddiskVolume9\Windows\SysWOW64\dbghelp.dll
> >
> > Which you then have to convert to the "normal" path every one else expects.
> > But I figured my way with GetSystemWow64Directory is simpler.
> >
> >
> > Is the v2 OK to commit?
>
> Yes, thanks.

Pushed, thanks.


Hannes