[PATCH v2] Fix WOW64 process system DLL paths

[PATCH v2] Fix WOW64 process system DLL paths

[Hannes Domani]

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
---
 gdb/windows-nat.c | 44 +++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 9c5ea5c046..8b7328946b 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1993,16 +1993,39 @@ windows_add_all_dlls (void)
 	return;
     }
 
+#ifdef __x86_64__
+  char system_dir[__PMAX];
+  char syswow_dir[__PMAX];
+  size_t system_dir_len = 0;
+  if (wow64_process)
+    {
+      UINT len = GetSystemDirectoryA (system_dir, sizeof (system_dir));
+      /* Error check.  */
+      gdb_assert (len != 0);
+      /* Check that we have passed a large enough buffer.  */
+      gdb_assert (len < sizeof (system_dir));
+
+      len = GetSystemWow64DirectoryA (syswow_dir, sizeof (syswow_dir));
+      /* Error check.  */
+      gdb_assert (len != 0);
+      /* Check that we have passed a large enough buffer.  */
+      gdb_assert (len < sizeof (syswow_dir));
+
+      strcat (system_dir, "\\");
+      strcat (syswow_dir, "\\");
+      system_dir_len = strlen (system_dir);
+    }
+#endif
   for (i = 1; i < (int) (cb_needed / sizeof (HMODULE)); i++)
     {
       MODULEINFO mi;
 #ifdef __USEWIDE
       wchar_t dll_name[__PMAX];
-      char name[__PMAX];
+      char dll_name_mb[__PMAX];
 #else
       char dll_name[__PMAX];
-      char *name;
 #endif
+      const char *name;
       if (GetModuleInformation (current_process_handle, hmodules[i],
 				&mi, sizeof (mi)) == 0)
 	continue;
@@ -2010,10 +2033,25 @@ windows_add_all_dlls (void)
 			       dll_name, sizeof (dll_name)) == 0)
 	continue;
 #ifdef __USEWIDE
-      wcstombs (name, dll_name, __PMAX);
+      wcstombs (dll_name_mb, dll_name, __PMAX);
+      name = dll_name_mb;
 #else
       name = dll_name;
 #endif
+#ifdef __x86_64__
+      /* Convert the DLL path of WOW64 processes returned by
+	 GetModuleFileNameEx from the 64bit system directory to the
+	 32bit syswow64 directory if necessary.  */
+      std::string syswow_dll_path;
+      if (wow64_process
+	  && strncasecmp (name, system_dir, system_dir_len) == 0
+	  && strchr (name + system_dir_len, '\\') == nullptr)
+	{
+	  syswow_dll_path = syswow_dir;
+	  syswow_dll_path += name + system_dir_len;
+	  name = syswow_dll_path.c_str();
+	}
+#endif
 
       solib_end->next = windows_make_so (name, mi.lpBaseOfDll);
       solib_end = solib_end->next;
-- 
2.25.2

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

[Simon Marchi]

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

Thanks, this is ok.

Simon

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

[Jon Turney]

On 24/03/2020 19:23, 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.
> 
[...]
>   #else
>         name = dll_name;
>   #endif
> +#ifdef __x86_64__
> +      /* Convert the DLL path of WOW64 processes returned by
> +	 GetModuleFileNameEx from the 64bit system directory to the
> +	 32bit syswow64 directory if necessary.  */
> +      std::string syswow_dll_path;
> +      if (wow64_process
> +	  && strncasecmp (name, system_dir, system_dir_len) == 0
> +	  && strchr (name + system_dir_len, '\\') == nullptr)
> +	{
> +	  syswow_dll_path = syswow_dir;
> +	  syswow_dll_path += name + system_dir_len;
> +	  name = syswow_dll_path.c_str();
> +	}
> +#endif
>   

DLLs we become aware of via handle_load_dll() don't get this treatment.

Can you share your reasoning about that?

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

[Hannes Domani]

 Am Mittwoch, 25. März 2020, 00:56:09 MEZ hat Jon Turney <jon.turney@dronecode.org.uk> Folgendes geschrieben:

> On 24/03/2020 19:23, 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.
> >
> [...]
> >  #else
> >        name = dll_name;
> >  #endif
> > +#ifdef __x86_64__
> > +      /* Convert the DLL path of WOW64 processes returned by
> > +    GetModuleFileNameEx from the 64bit system directory to the
> > +    32bit syswow64 directory if necessary.  */
> > +      std::string syswow_dll_path;
> > +      if (wow64_process
> > +      && strncasecmp (name, system_dir, system_dir_len) == 0
> > +      && strchr (name + system_dir_len, '\\') == nullptr)
> > +    {
> > +      syswow_dll_path = syswow_dir;
> > +      syswow_dll_path += name + system_dir_len;
> > +      name = syswow_dll_path.c_str();
> > +    }
> > +#endif
>
> >
>
> DLLs we become aware of via handle_load_dll() don't get this treatment.
>
> Can you share your reasoning about that?

Because I get these wrong paths only with GetModuleFileNameEx, and
LOAD_DLL_DEBUG_EVENT reports for the same dlls the correct path.

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

[Simon Marchi]

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

Simon

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

[Hannes Domani]

 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?


Hannes

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

[Simon Marchi]

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.

Simon

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

[Hannes Domani]

 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

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

[Eli Zaretskii]

> Date: Wed, 25 Mar 2020 14:35:51 +0000 (UTC)
> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> 
> > > But I figured my way with GetSystemWow64Directory is simpler.
> > >
> > >
> > > Is the v2 OK to commit?
> >
> > Yes, thanks.
> 
> Pushed, thanks.

It looks like the same problem exists in the 32-bit Windows build of
GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
on 64-bit Windows 7, for example).  So I guess the code which replaces
the former with the latter should also be in the 32-bit build, not
just "#ifdef __x86_64__".

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

[Hannes Domani]

 Am Donnerstag, 26. März 2020, 20:26:14 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:

> > Date: Wed, 25 Mar 2020 14:35:51 +0000 (UTC)
>
> > From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> >
> > > > But I figured my way with GetSystemWow64Directory is simpler.
> > > >
> > > >
> > > > Is the v2 OK to commit?
> > >
> > > Yes, thanks.
> >
> > Pushed, thanks.
>
>
> It looks like the same problem exists in the 32-bit Windows build of
> GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
> C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
> on 64-bit Windows 7, for example).  So I guess the code which replaces
> the former with the latter should also be in the 32-bit build, not
> just "#ifdef __x86_64__".

Yes, for me (on Win7) it also happens with the same dlls in the 32-bit gdb
as with the 64-bit gdb.
But it shouldn't matter, since for 32-bit gdb all C:\Windows\system32 paths
are automatically redirected[1] to C:\Windows\SysWOW64 anyways.

[1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector


Regards
Hannes Domani

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

[Christian Biesinger]

On Thu, Mar 26, 2020 at 3:35 PM Hannes Domani via Gdb-patches
<gdb-patches@sourceware.org> wrote:
>
>  Am Donnerstag, 26. März 2020, 20:26:14 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
>
> > > Date: Wed, 25 Mar 2020 14:35:51 +0000 (UTC)
> >
> > > From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> > >
> > > > > But I figured my way with GetSystemWow64Directory is simpler.
> > > > >
> > > > >
> > > > > Is the v2 OK to commit?
> > > >
> > > > Yes, thanks.
> > >
> > > Pushed, thanks.
> >
> >
> > It looks like the same problem exists in the 32-bit Windows build of
> > GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
> > C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
> > on 64-bit Windows 7, for example).  So I guess the code which replaces
> > the former with the latter should also be in the 32-bit build, not
> > just "#ifdef __x86_64__".
>
> Yes, for me (on Win7) it also happens with the same dlls in the 32-bit gdb
> as with the 64-bit gdb.
> But it shouldn't matter, since for 32-bit gdb all C:\Windows\system32 paths
> are automatically redirected[1] to C:\Windows\SysWOW64 anyways.
>
> [1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector

Even so, it's probably less confusing for the user if what GDB
displays actually matches reality?

Christian

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

[Hannes Domani]

 Am Donnerstag, 26. März 2020, 21:39:27 MEZ hat Christian Biesinger <cbiesinger@google.com> Folgendes geschrieben:

> On Thu, Mar 26, 2020 at 3:35 PM Hannes Domani via Gdb-patches
>
> <gdb-patches@sourceware.org> wrote:
> >
> >  Am Donnerstag, 26. März 2020, 20:26:14 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
> >
> > > > Date: Wed, 25 Mar 2020 14:35:51 +0000 (UTC)
> > >
> > > > From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> > > >
> > > > > > But I figured my way with GetSystemWow64Directory is simpler.
> > > > > >
> > > > > >
> > > > > > Is the v2 OK to commit?
> > > > >
> > > > > Yes, thanks.
> > > >
> > > > Pushed, thanks.
> > >
> > >
> > > It looks like the same problem exists in the 32-bit Windows build of
> > > GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
> > > C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
> > > on 64-bit Windows 7, for example).  So I guess the code which replaces
> > > the former with the latter should also be in the 32-bit build, not
> > > just "#ifdef __x86_64__".
> >
> > Yes, for me (on Win7) it also happens with the same dlls in the 32-bit gdb
> > as with the 64-bit gdb.
> > But it shouldn't matter, since for 32-bit gdb all C:\Windows\system32 paths
> > are automatically redirected[1] to C:\Windows\SysWOW64 anyways.
> >
> > [1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector
>
>
> Even so, it's probably less confusing for the user if what GDB
> displays actually matches reality?

I guess you are right.
I will prepare a patch for this.


Hannes

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

[Simon Marchi]

On 2020-03-26 4:48 p.m., Hannes Domani via Gdb-patches wrote:
>  Am Donnerstag, 26. März 2020, 21:39:27 MEZ hat Christian Biesinger <cbiesinger@google.com> Folgendes geschrieben:
> 
>> On Thu, Mar 26, 2020 at 3:35 PM Hannes Domani via Gdb-patches
>>
>> <gdb-patches@sourceware.org> wrote:
>>>
>>>   Am Donnerstag, 26. März 2020, 20:26:14 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
>>>
>>>>> Date: Wed, 25 Mar 2020 14:35:51 +0000 (UTC)
>>>>
>>>>> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
>>>>>
>>>>>>> But I figured my way with GetSystemWow64Directory is simpler.
>>>>>>>
>>>>>>>
>>>>>>> Is the v2 OK to commit?
>>>>>>
>>>>>> Yes, thanks.
>>>>>
>>>>> Pushed, thanks.
>>>>
>>>>
>>>> It looks like the same problem exists in the 32-bit Windows build of
>>>> GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
>>>> C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
>>>> on 64-bit Windows 7, for example).  So I guess the code which replaces
>>>> the former with the latter should also be in the 32-bit build, not
>>>> just "#ifdef __x86_64__".
>>>
>>> Yes, for me (on Win7) it also happens with the same dlls in the 32-bit gdb
>>> as with the 64-bit gdb.
>>> But it shouldn't matter, since for 32-bit gdb all C:\Windows\system32 paths
>>> are automatically redirected[1] to C:\Windows\SysWOW64 anyways.
>>>
>>> [1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector
>>
>>
>> Even so, it's probably less confusing for the user if what GDB
>> displays actually matches reality?
> 
> I guess you are right.
> I will prepare a patch for this.

Let's say a 32 bit GDB is debugging a 64 bit program.  GDB gets the list of loaded libraries, which
contains c:\windows\system32\foo.dll.  When GDB opens it, to read the contents of the library, will
it open and read c:\windows\system32\foo.dll (which is the one really loaded in the 64-bit process)
or will it open and read c:\windows\syswow64\foo.dll?

Simon

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

[Hannes Domani]

 Am Donnerstag, 26. März 2020, 21:57:00 MEZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:

> On 2020-03-26 4:48 p.m., Hannes Domani via Gdb-patches wrote:
>
> >  Am Donnerstag, 26. März 2020, 21:39:27 MEZ hat Christian Biesinger <cbiesinger@google.com> Folgendes geschrieben:
> >
> >> On Thu, Mar 26, 2020 at 3:35 PM Hannes Domani via Gdb-patches
> >>
> >> <gdb-patches@sourceware.org> wrote:
> >>>
> >>>   Am Donnerstag, 26. März 2020, 20:26:14 MEZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
> >>>
> >>>>> Date: Wed, 25 Mar 2020 14:35:51 +0000 (UTC)
> >>>>
> >>>>> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> >>>>>
> >>>>>>> But I figured my way with GetSystemWow64Directory is simpler.
> >>>>>>>
> >>>>>>>
> >>>>>>> Is the v2 OK to commit?
> >>>>>>
> >>>>>> Yes, thanks.
> >>>>>
> >>>>> Pushed, thanks.
> >>>>
> >>>>
> >>>> It looks like the same problem exists in the 32-bit Windows build of
> >>>> GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
> >>>> C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
> >>>> on 64-bit Windows 7, for example).  So I guess the code which replaces
> >>>> the former with the latter should also be in the 32-bit build, not
> >>>> just "#ifdef __x86_64__".
> >>>
> >>> Yes, for me (on Win7) it also happens with the same dlls in the 32-bit gdb
> >>> as with the 64-bit gdb.
> >>> But it shouldn't matter, since for 32-bit gdb all C:\Windows\system32 paths
> >>> are automatically redirected[1] to C:\Windows\SysWOW64 anyways.
> >>>
> >>> [1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector
> >>
> >>
> >> Even so, it's probably less confusing for the user if what GDB
> >> displays actually matches reality?
> >
> > I guess you are right.
> > I will prepare a patch for this.
>
>
> Let's say a 32 bit GDB is debugging a 64 bit program.  GDB gets the list of loaded libraries, which
> contains c:\windows\system32\foo.dll.  When GDB opens it, to read the contents of the library, will
> it open and read c:\windows\system32\foo.dll (which is the one really loaded in the 64-bit process)
> or will it open and read c:\windows\syswow64\foo.dll?

You can't debug a 64-bit program with a 32-bit gdb, it's only possible
the other way around.

But if it were possible, it would read c:\windows\syswow64\foo.dll.

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

[Simon Marchi]

On 2020-03-26 5:01 p.m., Hannes Domani via Gdb-patches wrote:
> You can't debug a 64-bit program with a 32-bit gdb, it's only possible
> the other way around.
> 
> But if it were possible, it would read c:\windows\syswow64\foo.dll.

Thanks, that settles it.

Simon

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

[Eli Zaretskii]

> Date: Thu, 26 Mar 2020 20:48:35 +0000 (UTC)
> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> 
> > > [1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector
> >
> >
> > Even so, it's probably less confusing for the user if what GDB
> > displays actually matches reality?
> 
> I guess you are right.
> I will prepare a patch for this.

Thank you.

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

[Eli Zaretskii]

> Date: Thu, 26 Mar 2020 20:35:31 +0000 (UTC)
> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>
> 
> > It looks like the same problem exists in the 32-bit Windows build of
> > GDB, when it runs on 64-bit Windows 10: "info sharedlibrary" shows
> > C:\Windows\system32 instead of C:\Windows\SysWOW64 (it doesn't happen
> > on 64-bit Windows 7, for example).  So I guess the code which replaces
> > the former with the latter should also be in the 32-bit build, not
> > just "#ifdef __x86_64__".
> 
> Yes, for me (on Win7) it also happens with the same dlls in the 32-bit gdb
> as with the 64-bit gdb.
> But it shouldn't matter, since for 32-bit gdb all C:\Windows\system32 paths
> are automatically redirected[1] to C:\Windows\SysWOW64 anyways.
> 
> [1] https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector

I know, but "info sharedlibrary" is a user command, and we shouldn't
really expect all our users to be aware of this redirection.  the code
is already there, so all we need is to remove 2 #ifdef's and use
what's already there.  WDYT?