Re: Support of gdb for Windows 64 native systems

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

[redirecting to gdb-patches]
On Sun, Oct 14, 2007 at 12:43:01PM +0100, Pedro Alves wrote:
> Joel Brobecker wrote:
>>> Not sure who you're asking that, but, I'm not doing or going to do
>>> anything, since you're already about to :)
>> OK :). I don't have much time these days, and in fact, I wasn't
>> really supposed to dedicate the 4+ hours I have already spent on
>> this, but since we seem to be on a roll, I'll try to spend some
>> time on it next week to start the process and get us a minimal
>> MinGW debugger.
>
> Nah, nah, na-na-naaah.  I've done it, and I said wouldn't  :)
>
> Seriously, and rethinking a bit after sleep, it is safer to do
> it from scratch, so the copyright issues are cleared.
>
> The initial changes are pretty mechanic, so, here goes.
>
> What's done:
>
> 	- Added mingw.mh, mingw.mt as copies from the cygwin files.
> 	- Updated configure.tgt to set gdb_target.
> 	- Disabled cygwin specific functionality in win32-nat.c.  As can
> 	be seen, the changes are very small.
> 	- profs.h isn't needed anymore, since I've implemented cygwin cross-core 
> support a few weeks ago (in i386-cygwin-tdep.c).  The include can be
> 	unconditionally removed.
>
> What's next:
>
> 	Test with a mingw built libexpat to test dll support.
>
> 	win32_pid_to_exec_file:  Could be done with GetModuleFileNameEx
> 	from PSAPI and/or with toolhelp.
>
> 	Rename a few things, which really aren't cygwin specific, like:
> 		* cygwin_get_dr6 -> win32_get_dr6
> 		* i386-cygwin-tdep.h -> i386-win32-tdep.h
> 		* nm-cygwin.h -> nm-cygming.h
>
> What's disabled:
> 	Use a shell to start the subprocess.
>
> I'm sure there are other problems, but it is useable already.
>
> cygcheck.exe ./gdb.exe
> .\gdb.exe
>   C:\WINDOWS\system32\KERNEL32.dll
>     C:\WINDOWS\system32\ntdll.dll
>   C:\WINDOWS\system32\msvcrt.dll
>   C:\WINDOWS\system32\USER32.dll
>     C:\WINDOWS\system32\GDI32.dll
>   C:\WINDOWS\system32\WS2_32.DLL
>     C:\WINDOWS\system32\WS2HELP.dll
>       C:\WINDOWS\system32\ADVAPI32.dll
>         C:\WINDOWS\system32\RPCRT4.dll
>           C:\WINDOWS\system32\Secur32.dll
>
> build-gdb_mingw\gdb>gdb ./gdb.exe
> GNU gdb 6.7.50-20071012-cvs
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "mingw32"...
> Setting up the environment for debugging gdb.
> During symbol reading, struct/union type gets multiply defined: struct 
> type.
> Breakpoint 1 at 0x40b513: file ../../gdb-server_submit/src/gdb/utils.c, 
> line 817
> .
> Breakpoint 2 at 0x4185c6: file 
> ../../gdb-server_submit/src/gdb/cli/cli-cmds.c, l
> ine 199.
> (top-gdb) start
> Breakpoint 3 at 0x401309: file ../../gdb-server_submit/src/gdb/gdb.c, line 
> 28.
> Starting program: D:\cegccsf\cegcc\cegcc\src\build-gdb_mingw\gdb/./gdb.exe
> warning: Can not parse XML library list; XML support was disabled at 
> compile tim
> e
> main (argc=1, argv=0x3d24f0) at ../../gdb-server_submit/src/gdb/gdb.c:28
> 28        memset (&args, 0, sizeof args);
>
> Cheers,
> Pedro Alves

>2007-10-14  Pedro Alves  <pedro_alves@portugalmail.pt>
>
>	* config/i386/mingw.mh, config/i386/mingw.mt: New files.
>	* configure.tgt	(i[34567]86-*-mingw32*): Set gdb_target = mingw.
>	* win32-nat.c: Only include cygwin.h on Cygwin host.  Don't
>	include procfs.h.
>	(win32_make_so): Don't convert path to posix on MinGW.
>	(win32_attach): Only fallback to Cygwin pids on Cygwin.
>	(win32_pid_to_exec_file): Disable Cygwin specific code.
>	(win32_create_inferior): Disable handle starting the inferior
>	through a shell on MinGW.  Disable environment var processing.
>	Disable tty handling.
>	(cygwin_pid_to_str): Rename to ...
>	(win32_pid_to_str): ... this.
>	(init_win32_ops): Update use of win32_pid_to_str.  Disable "shell"
>	command on MinGW.
>
>---
> gdb/config/i386/mingw.mh |    4 ++++
> gdb/config/i386/mingw.mt |    3 +++
> gdb/configure.tgt        |    2 +-
> gdb/win32-nat.c          |   44 ++++++++++++++++++++++++++++++++++----------
> 4 files changed, 42 insertions(+), 11 deletions(-)
>
>Index: src/gdb/config/i386/mingw.mh
>===================================================================
>--- /dev/null	1970-01-01 00:00:00.000000000 +0000
>+++ src/gdb/config/i386/mingw.mh	2007-10-14 12:19:44.000000000 +0100
>@@ -0,0 +1,4 @@
>+MH_CFLAGS=
>+NATDEPFILES= i386-nat.o win32-nat.o
>+NAT_FILE=nm-cygwin.h
>+XM_CLIBS=
>Index: src/gdb/config/i386/mingw.mt
>===================================================================
>--- /dev/null	1970-01-01 00:00:00.000000000 +0000
>+++ src/gdb/config/i386/mingw.mt	2007-10-14 10:36:20.000000000 +0100
>@@ -0,0 +1,3 @@
>+# Target: Intel 386 run win32
>+TDEPFILES= i386-tdep.o i386-cygwin-tdep.o i387-tdep.o \
>+	   solib-target.o corelow.o
>Index: src/gdb/configure.tgt
>===================================================================
>--- src.orig/gdb/configure.tgt	2007-10-12 20:25:20.000000000 +0100
>+++ src/gdb/configure.tgt	2007-10-14 11:19:50.000000000 +0100
>@@ -120,7 +120,7 @@ i[34567]86-*-gnu*)	gdb_target=i386gnu ;;
> i[34567]86-*-cygwin*)	gdb_target=cygwin
> 			build_gdbserver=yes
> 			;;
>-i[34567]86-*-mingw32*)	gdb_target=i386
>+i[34567]86-*-mingw32*)	gdb_target=mingw
> 			build_gdbserver=yes
> 			;;
> i[34567]86-*-*)		gdb_target=i386 ;;
>Index: src/gdb/win32-nat.c
>===================================================================
>--- src.orig/gdb/win32-nat.c	2007-10-13 02:27:04.000000000 +0100
>+++ src/gdb/win32-nat.c	2007-10-14 12:23:22.000000000 +0100
>@@ -22,8 +22,6 @@
> 
> /* Originally by Steve Chamberlain, sac@cygnus.com */
> 
>-/* We assume we're being built with and will be used for cygwin.  */
>-
> #include "defs.h"
> #include "frame.h"		/* required by inferior.h */
> #include "inferior.h"
>@@ -40,7 +38,9 @@
> #include <stdlib.h>
> #include <windows.h>
> #include <imagehlp.h>
>+#ifdef __CYGWIN__
> #include <sys/cygwin.h>
>+#endif
> #include <signal.h>
> 
> #include "buildsym.h"
>@@ -81,7 +81,6 @@ enum
>     CONTEXT_DEBUGGER = (CONTEXT_FULL | CONTEXT_FLOATING_POINT)
>   };
> #endif
>-#include <sys/procfs.h>
> #include <psapi.h>
> 
> #define CONTEXT_DEBUGGER_DR CONTEXT_DEBUGGER | CONTEXT_DEBUG_REGISTERS \
>@@ -637,7 +636,11 @@ win32_make_so (const char *name, DWORD l
>   so = XZALLOC (struct so_list);
>   so->lm_info = (struct lm_info *) xmalloc (sizeof (struct lm_info));
>   so->lm_info->load_addr = load_addr;
>+#ifdef __CYGWIN__
>   cygwin_conv_to_posix_path (buf, so->so_name);
>+#else
>+  strcpy (so->so_name, buf);
>+#endif
>   strcpy (so->so_original_name, name);
> 
>   /* Record cygwin1.dll .text start/end.  */
>@@ -1625,6 +1628,7 @@ win32_attach (char *args, int from_tty)
>   ok = DebugActiveProcess (pid);
>   saw_create = 0;
> 
>+#ifdef __CYGWIN__
>   if (!ok)
>     {
>       /* Try fall back to Cygwin pid */
>@@ -1632,10 +1636,11 @@ win32_attach (char *args, int from_tty)
> 
>       if (pid > 0)
> 	ok = DebugActiveProcess (pid);
>+  }
>+#endif
> 
>-      if (!ok)
>-	error (_("Can't attach to process."));
>-    }
>+  if (!ok)
>+    error (_("Can't attach to process."));
> 
>   if (has_detach_ability ())
>     DebugSetProcessKillOnExit (FALSE);
>@@ -1697,10 +1702,12 @@ win32_pid_to_exec_file (int pid)
>   /* Try to find the process path using the Cygwin internal process list
>      pid isn't a valid pid, unfortunately.  Use current_event.dwProcessId
>      instead.  */
>-  /* TODO: Also find native Windows processes using CW_GETPINFO_FULL.  */
> 
>   static char path[MAX_PATH + 1];
>   char *path_ptr = NULL;
>+
>+#ifdef __CYGWIN__
>+  /* TODO: Also find native Windows processes using CW_GETPINFO_FULL.  */
>   int cpid;
>   struct external_pinfo *pinfo;
> 
>@@ -1718,6 +1725,10 @@ win32_pid_to_exec_file (int pid)
>        }
>     }
>   cygwin_internal (CW_UNLOCK_PINFO);
>+  if (path_ptr)
>+    return path_ptr;
>+#endif
>+
>   return path_ptr;
> }
> 
>@@ -1764,9 +1775,12 @@ win32_create_inferior (char *exec_file, 
>   memset (&si, 0, sizeof (si));
>   si.cb = sizeof (si);
> 
>+  flags = DEBUG_ONLY_THIS_PROCESS;
>+  toexec = exec_file;

This doesn't seem right.  You moved this setting outside of an if block
and didn't accommodate the else condition.

>+
>+#ifdef __CYGWIN__
>   if (!useshell)
>     {
>-      flags = DEBUG_ONLY_THIS_PROCESS;
>       cygwin_conv_to_win32_path (exec_file, real_path);
>       toexec = real_path;
>     }
>@@ -1784,6 +1798,7 @@ win32_create_inferior (char *exec_file, 
>       toexec = shell;
>       flags = DEBUG_PROCESS;
>     }
>+#endif
> 
>   if (new_group)
>     flags |= CREATE_NEW_PROCESS_GROUP;
>@@ -1798,6 +1813,8 @@ win32_create_inferior (char *exec_file, 
>   strcat (args, " ");
>   strcat (args, allargs);
> 
>+#ifdef __CYGWIN__
>+
>   /* Prepare the environment vars for CreateProcess.  */
>   cygwin_internal (CW_SYNC_WINENV);
> 
>@@ -1822,6 +1839,8 @@ win32_create_inferior (char *exec_file, 
> 	}
>     }
> 
>+#endif
>+
>   win32_init_thread_list ();
>   ret = CreateProcess (0,
> 		       args,	/* command line */
>@@ -1833,6 +1852,8 @@ win32_create_inferior (char *exec_file, 
> 		       NULL,	/* current directory */
> 		       &si,
> 		       &pi);
>+
>+#ifdef __CYGWIN__
>   if (tty >= 0)
>     {
>       close (tty);
>@@ -1843,6 +1864,7 @@ win32_create_inferior (char *exec_file, 
>       close (ostdout);
>       close (ostderr);
>     }
>+#endif
> 
>   if (!ret)
>     error (_("Error creating process %s, (error %d)."),
>@@ -1951,7 +1973,7 @@ win32_close (int x)
> 
> /* Convert pid to printable format. */
> static char *
>-cygwin_pid_to_str (ptid_t ptid)
>+win32_pid_to_str (ptid_t ptid)
> {
>   static char buf[80];
>   int pid = PIDGET (ptid);
>@@ -2055,7 +2077,7 @@ init_win32_ops (void)
>   win32_ops.to_mourn_inferior = win32_mourn_inferior;
>   win32_ops.to_can_run = win32_can_run;
>   win32_ops.to_thread_alive = win32_win32_thread_alive;
>-  win32_ops.to_pid_to_str = cygwin_pid_to_str;
>+  win32_ops.to_pid_to_str = win32_pid_to_str;
>   win32_ops.to_stop = win32_stop;
>   win32_ops.to_stratum = process_stratum;
>   win32_ops.to_has_all_memory = 1;
>@@ -2086,12 +2108,14 @@ _initialize_win32_nat (void)
> 
>   add_com_alias ("sharedlibrary", "dll-symbols", class_alias, 1);
> 
>+#ifdef __CYGWIN__
>   add_setshow_boolean_cmd ("shell", class_support, &useshell, _("\
> Set use of shell to start subprocess."), _("\
> Show use of shell to start subprocess."), NULL,
> 			   NULL,
> 			   NULL, /* FIXME: i18n: */
> 			   &setlist, &showlist);
>+#endif
> 
>   add_setshow_boolean_cmd ("cygwin-exceptions", class_support, &cygwin_exceptions, _("\
> Break when an exception is detected in the Cygwin DLL itself."), _("\

Seems like the above should be ifdef'ed too.

cgf

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Christopher Faylor wrote:
>> +  flags = DEBUG_ONLY_THIS_PROCESS;
>> +  toexec = exec_file;
> 
> This doesn't seem right.  You moved this setting outside of an if block
> and didn't accommodate the else condition.
> 

I didn't move it.  The if inside the __CYGWIN__ block sets TOEXEC in both
branches.

Here is rest of the hunk:
>> +
>> +#ifdef __CYGWIN__
>>   if (!useshell)
>>     {
>> -      flags = DEBUG_ONLY_THIS_PROCESS;
>>       cygwin_conv_to_win32_path (exec_file, real_path);
>>       toexec = real_path;
>>     }
>> @@ -1784,6 +1798,7 @@ win32_create_inferior (char *exec_file,
>>       toexec = shell;
>>       flags = DEBUG_PROCESS;
>>     }
>> +#endif

This is what the resulting code looks like after the patch is applied:

   flags = DEBUG_ONLY_THIS_PROCESS;
   toexec = exec_file;

#ifdef __CYGWIN__
   if (!useshell)
     {
       cygwin_conv_to_win32_path (exec_file, real_path);
       toexec = real_path;
     }
   else
     {
       char *newallargs;
       sh = getenv ("SHELL");
       if (!sh)
	sh = "/bin/sh";
       cygwin_conv_to_win32_path (sh, shell);
       newallargs = alloca (sizeof (" -c 'exec  '") + strlen (exec_file)
			   + strlen (allargs) + 2);
       sprintf (newallargs, " -c 'exec %s %s'", exec_file, allargs);
       allargs = newallargs;
       toexec = shell;
       flags = DEBUG_PROCESS;
     }
#endif

It could be changed into:

#ifdef __CYGWIN__
...
#else
   toexec = exec_file;
#endif

I prefer how it is now, but I'll respect your decision.

>> +#ifdef __CYGWIN__
>>   add_setshow_boolean_cmd ("shell", class_support, &useshell, _("\
>> Set use of shell to start subprocess."), _("\
>> Show use of shell to start subprocess."), NULL,
>> 			   NULL,
>> 			   NULL, /* FIXME: i18n: */
>> 			   &setlist, &showlist);
>> +#endif
>>
>>   add_setshow_boolean_cmd ("cygwin-exceptions", class_support, &cygwin_exceptions, _("\
>> Break when an exception is detected in the Cygwin DLL itself."), _("\
> 
> Seems like the above should be ifdef'ed too.
> 

Not sure why.  The cygwin1.dll dll detection doesn't depend on any host
habilities.  Having a mingw hosted gdb be able to attach to a cygwin
executable, and being able to debug it, seems useful.  I imagine that
it might prove useful to have a gdb that doesn't link to cygwin1.dll
as a resort into debugging Cygwin issues.

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Sun, Oct 14, 2007 at 07:02:26PM +0100, Pedro Alves wrote:
> Christopher Faylor wrote:
>>> +  flags = DEBUG_ONLY_THIS_PROCESS;
>>> +  toexec = exec_file;
>> This doesn't seem right.  You moved this setting outside of an if block
>> and didn't accommodate the else condition.
>
> I didn't move it.  The if inside the __CYGWIN__ block sets TOEXEC in both
> branches.

I'm talking about "flags".

> Here is rest of the hunk:
>>> +
>>> +#ifdef __CYGWIN__
>>>   if (!useshell)
>>>     {
>>> -      flags = DEBUG_ONLY_THIS_PROCESS;
>>>       cygwin_conv_to_win32_path (exec_file, real_path);
>>>       toexec = real_path;
>>>     }
>>> @@ -1784,6 +1798,7 @@ win32_create_inferior (char *exec_file,
>>>       toexec = shell;
>>>       flags = DEBUG_PROCESS;
>>>     }
>>> +#endif
>
> This is what the resulting code looks like after the patch is applied:
>
>   flags = DEBUG_ONLY_THIS_PROCESS;
>   toexec = exec_file;
>
> #ifdef __CYGWIN__
>   if (!useshell)
>     {
>       cygwin_conv_to_win32_path (exec_file, real_path);
>       toexec = real_path;
>     }
>   else
>     {
>       char *newallargs;
>       sh = getenv ("SHELL");
>       if (!sh)
> 	sh = "/bin/sh";
>       cygwin_conv_to_win32_path (sh, shell);
>       newallargs = alloca (sizeof (" -c 'exec  '") + strlen (exec_file)
> 			   + strlen (allargs) + 2);
>       sprintf (newallargs, " -c 'exec %s %s'", exec_file, allargs);
>       allargs = newallargs;
>       toexec = shell;
>       flags = DEBUG_PROCESS;
>     }
> #endif
>
> It could be changed into:
>
> #ifdef __CYGWIN__
> ...
> #else
>   toexec = exec_file;
> #endif
>
> I prefer how it is now, but I'll respect your decision.
>
>>> +#ifdef __CYGWIN__
>>>   add_setshow_boolean_cmd ("shell", class_support, &useshell, _("\
>>> Set use of shell to start subprocess."), _("\
>>> Show use of shell to start subprocess."), NULL,
>>> 			   NULL,
>>> 			   NULL, /* FIXME: i18n: */
>>> 			   &setlist, &showlist);
>>> +#endif
>>>
>>>   add_setshow_boolean_cmd ("cygwin-exceptions", class_support, 
>>> &cygwin_exceptions, _("\
>>> Break when an exception is detected in the Cygwin DLL itself."), _("\
>> Seems like the above should be ifdef'ed too.
>
> Not sure why.  The cygwin1.dll dll detection doesn't depend on any host
> habilities.  Having a mingw hosted gdb be able to attach to a cygwin
> executable, and being able to debug it, seems useful.  I imagine that
> it might prove useful to have a gdb that doesn't link to cygwin1.dll
> as a resort into debugging Cygwin issues.

There should be no cygwin accommodations in a pure windows port of gdb.

cgf

Re: Support of gdb for Windows 64 native systems

[Daniel Jacobowitz]

On Sun, Oct 14, 2007 at 06:16:03PM -0400, Christopher Faylor wrote:
> There should be no cygwin accommodations in a pure windows port of gdb.

Why?  A native Windows GDB that can usefully debug Cygwin programs
seems convenient to me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Sun, Oct 14, 2007 at 06:22:52PM -0400, Daniel Jacobowitz wrote:
>On Sun, Oct 14, 2007 at 06:16:03PM -0400, Christopher Faylor wrote:
>> There should be no cygwin accommodations in a pure windows port of gdb.
>
>Why?  A native Windows GDB that can usefully debug Cygwin programs
>seems convenient to me.

I just don't see why it should care about Cygwin.  Why complicate the
code with special case operations for cygwin when there is already a
cygwin port?  I doubt that this version of gdb would correctly translate
cygwin paths built into the executable so it seems like it would just
be a basically unused feature.

cgf

Re: Support of gdb for Windows 64 native systems

[Daniel Jacobowitz]

On Mon, Oct 15, 2007 at 02:45:25PM -0400, Christopher Faylor wrote:
> I just don't see why it should care about Cygwin.  Why complicate the
> code with special case operations for cygwin when there is already a
> cygwin port?  I doubt that this version of gdb would correctly translate
> cygwin paths built into the executable so it seems like it would just
> be a basically unused feature.

I hadn't thought about that.  I suppose not.  Although we
(CodeSourcery) do have some scary libiberty bits to call out to a
Cygwin DLL or cygpath binary, for other programs... it's probably
possible to make that work in GDB but I'm not sure of the value
either.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

   On Mon, Oct 15, 2007 at 02:45:25PM -0400, Christopher Faylor wrote:
> I just don't see why it should care about Cygwin.  Why complicate the
> code with special case operations for cygwin when there is already a
> cygwin port?  I doubt that this version of gdb would correctly translate
> cygwin paths built into the executable so it seems like it would just
> be a basically unused feature.

You convinced me.

Following your remark:
  >There should be no cygwin accommodations in a pure windows port of gdb.

How about the attached?

Cheers,
Pedro Alves


[-- Attachment #2: mingw.diff --]
[-- Type: text/x-diff, Size: 9620 bytes --]

2007-10-14  Pedro Alves  <pedro_alves@portugalmail.pt>

	* config/i386/mingw.mh, config/i386/mingw.mt: New files.
	
	* configure.tgt	(i[34567]86-*-mingw32*): Set gdb_target = mingw.
	
	* win32-nat.c: Only include cygwin.h on Cygwin host.  Don't
	include procfs.h.
	(cygwin_load_start, cygwin_load_end, cygwin_exceptions): Disable
	if not building for Cygwin.
	(win32_make_so, handle_output_debug_string, handle_exception)
	(do_initial_win32_stuff): Wrap Cygwin specific code in __CYGWIN__.
	(win32_attach): Only fallback to Cygwin pids on Cygwin.
	(win32_pid_to_exec_file): Disable Cygwin specific code.
	(win32_create_inferior): Disable starting the inferior through a
	shell, environment var processing and tty handling if not building
	on Cygwin.
	(cygwin_pid_to_str): Rename to ...
	(win32_pid_to_str): ... this.
	(init_win32_ops): Update use of win32_pid_to_str.  Disable "shell"
	and "cygwin-exceptions" commands if not building on Cygwin.

---
 gdb/config/i386/mingw.mh |    4 +++
 gdb/config/i386/mingw.mt |    3 ++
 gdb/configure.tgt        |    2 -
 gdb/win32-nat.c          |   52 +++++++++++++++++++++++++++++++++++++----------
 4 files changed, 49 insertions(+), 12 deletions(-)

Index: src/gdb/config/i386/mingw.mh
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ src/gdb/config/i386/mingw.mh	2007-10-15 00:40:58.000000000 +0100
@@ -0,0 +1,4 @@
+MH_CFLAGS=
+NATDEPFILES= i386-nat.o win32-nat.o
+NAT_FILE=nm-cygwin.h
+XM_CLIBS=
Index: src/gdb/config/i386/mingw.mt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ src/gdb/config/i386/mingw.mt	2007-10-15 00:40:58.000000000 +0100
@@ -0,0 +1,3 @@
+# Target: Intel 386 run win32
+TDEPFILES= i386-tdep.o i386-cygwin-tdep.o i387-tdep.o \
+	   solib-target.o corelow.o
Index: src/gdb/configure.tgt
===================================================================
--- src.orig/gdb/configure.tgt	2007-10-15 00:40:12.000000000 +0100
+++ src/gdb/configure.tgt	2007-10-15 00:40:58.000000000 +0100
@@ -120,7 +120,7 @@ i[34567]86-*-gnu*)	gdb_target=i386gnu ;;
 i[34567]86-*-cygwin*)	gdb_target=cygwin
 			build_gdbserver=yes
 			;;
-i[34567]86-*-mingw32*)	gdb_target=i386
+i[34567]86-*-mingw32*)	gdb_target=mingw
 			build_gdbserver=yes
 			;;
 i[34567]86-*-*)		gdb_target=i386 ;;
Index: src/gdb/win32-nat.c
===================================================================
--- src.orig/gdb/win32-nat.c	2007-10-15 00:40:12.000000000 +0100
+++ src/gdb/win32-nat.c	2007-10-15 23:51:48.000000000 +0100
@@ -22,8 +22,6 @@
 
 /* Originally by Steve Chamberlain, sac@cygnus.com */
 
-/* We assume we're being built with and will be used for cygwin.  */
-
 #include "defs.h"
 #include "frame.h"		/* required by inferior.h */
 #include "inferior.h"
@@ -40,7 +38,9 @@
 #include <stdlib.h>
 #include <windows.h>
 #include <imagehlp.h>
+#ifdef __CYGWIN__
 #include <sys/cygwin.h>
+#endif
 #include <signal.h>
 
 #include "buildsym.h"
@@ -64,9 +64,11 @@
 
 static struct target_ops win32_ops;
 
+#ifdef __CYGWIN__
 /* The starting and ending address of the cygwin1.dll text segment. */
 static bfd_vma cygwin_load_start;
 static bfd_vma cygwin_load_end;
+#endif
 
 static int have_saved_context;	/* True if we've saved context from a cygwin signal. */
 static CONTEXT saved_context;	/* Containes the saved context from a cygwin signal. */
@@ -81,7 +83,6 @@ enum
     CONTEXT_DEBUGGER = (CONTEXT_FULL | CONTEXT_FLOATING_POINT)
   };
 #endif
-#include <sys/procfs.h>
 #include <psapi.h>
 
 #define CONTEXT_DEBUGGER_DR CONTEXT_DEBUGGER | CONTEXT_DEBUG_REGISTERS \
@@ -142,7 +143,9 @@ static int saw_create;
 
 /* User options. */
 static int new_console = 0;
+#ifdef __CYGWIN__
 static int cygwin_exceptions = 0;
+#endif
 static int new_group = 1;
 static int debug_exec = 0;		/* show execution */
 static int debug_events = 0;		/* show events from kernel */
@@ -637,9 +640,11 @@ win32_make_so (const char *name, DWORD l
   so = XZALLOC (struct so_list);
   so->lm_info = (struct lm_info *) xmalloc (sizeof (struct lm_info));
   so->lm_info->load_addr = load_addr;
-  cygwin_conv_to_posix_path (buf, so->so_name);
   strcpy (so->so_original_name, name);
-
+#ifndef __CYGWIN__
+  strcpy (so->so_name, buf);
+#else
+  cygwin_conv_to_posix_path (buf, so->so_name);
   /* Record cygwin1.dll .text start/end.  */
   p = strchr (so->so_name, '\0') - (sizeof ("/cygwin1.dll") - 1);
   if (p >= so->so_name && strcasecmp (p, "/cygwin1.dll") == 0)
@@ -670,6 +675,7 @@ win32_make_so (const char *name, DWORD l
 
       bfd_close (abfd);
     }
+#endif
 
   return so;
 }
@@ -819,7 +825,9 @@ handle_output_debug_string (struct targe
     /* nothing to do */;
   else if (strncmp (s, _CYGWIN_SIGNAL_STRING, sizeof (_CYGWIN_SIGNAL_STRING) - 1) != 0)
     {
+#ifdef __CYGWIN__
       if (strncmp (s, "cYg", 3) != 0)
+#endif
 	warning (("%s"), s);
     }
 #ifdef __COPY_CONTEXT_SIZE
@@ -997,6 +1005,7 @@ handle_exception (struct target_waitstat
     case EXCEPTION_ACCESS_VIOLATION:
       DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_ACCESS_VIOLATION");
       ourstatus->value.sig = TARGET_SIGNAL_SEGV;
+#ifdef __CYGWIN__
       {
 	/* See if the access violation happened within the cygwin DLL itself.  Cygwin uses
 	   a kind of exception handling to deal with passed-in invalid addresses. gdb
@@ -1011,6 +1020,7 @@ handle_exception (struct target_waitstat
 		&& strncmp (fn, "KERNEL32!IsBad", strlen ("KERNEL32!IsBad")) == 0))
 	  return 0;
       }
+#endif
       break;
     case STATUS_STACK_OVERFLOW:
       DEBUG_EXCEPTION_SIMPLE ("STATUS_STACK_OVERFLOW");
@@ -1472,7 +1482,9 @@ do_initial_win32_stuff (DWORD pid)
   debug_registers_used = 0;
   for (i = 0; i < sizeof (dr) / sizeof (dr[0]); i++)
     dr[i] = 0;
+#ifdef __CYGWIN__
   cygwin_load_start = cygwin_load_end = 0;
+#endif
   current_event.dwProcessId = pid;
   memset (&current_event, 0, sizeof (current_event));
   push_target (&win32_ops);
@@ -1625,6 +1637,7 @@ win32_attach (char *args, int from_tty)
   ok = DebugActiveProcess (pid);
   saw_create = 0;
 
+#ifdef __CYGWIN__
   if (!ok)
     {
       /* Try fall back to Cygwin pid */
@@ -1632,10 +1645,11 @@ win32_attach (char *args, int from_tty)
 
       if (pid > 0)
 	ok = DebugActiveProcess (pid);
+  }
+#endif
 
-      if (!ok)
-	error (_("Can't attach to process."));
-    }
+  if (!ok)
+    error (_("Can't attach to process."));
 
   if (has_detach_ability ())
     DebugSetProcessKillOnExit (FALSE);
@@ -1697,10 +1711,12 @@ win32_pid_to_exec_file (int pid)
   /* Try to find the process path using the Cygwin internal process list
      pid isn't a valid pid, unfortunately.  Use current_event.dwProcessId
      instead.  */
-  /* TODO: Also find native Windows processes using CW_GETPINFO_FULL.  */
 
   static char path[MAX_PATH + 1];
   char *path_ptr = NULL;
+
+#ifdef __CYGWIN__
+  /* TODO: Also find native Windows processes using CW_GETPINFO_FULL.  */
   int cpid;
   struct external_pinfo *pinfo;
 
@@ -1718,6 +1734,8 @@ win32_pid_to_exec_file (int pid)
        }
     }
   cygwin_internal (CW_UNLOCK_PINFO);
+#endif
+
   return path_ptr;
 }
 
@@ -1764,6 +1782,7 @@ win32_create_inferior (char *exec_file, 
   memset (&si, 0, sizeof (si));
   si.cb = sizeof (si);
 
+#ifdef __CYGWIN__
   if (!useshell)
     {
       flags = DEBUG_ONLY_THIS_PROCESS;
@@ -1784,6 +1803,10 @@ win32_create_inferior (char *exec_file, 
       toexec = shell;
       flags = DEBUG_PROCESS;
     }
+#else
+  toexec = exec_file;
+  flags = DEBUG_ONLY_THIS_PROCESS;
+#endif
 
   if (new_group)
     flags |= CREATE_NEW_PROCESS_GROUP;
@@ -1798,6 +1821,7 @@ win32_create_inferior (char *exec_file, 
   strcat (args, " ");
   strcat (args, allargs);
 
+#ifdef __CYGWIN__
   /* Prepare the environment vars for CreateProcess.  */
   cygwin_internal (CW_SYNC_WINENV);
 
@@ -1821,6 +1845,7 @@ win32_create_inferior (char *exec_file, 
 	  dup2 (tty, 2);
 	}
     }
+#endif
 
   win32_init_thread_list ();
   ret = CreateProcess (0,
@@ -1833,6 +1858,8 @@ win32_create_inferior (char *exec_file, 
 		       NULL,	/* current directory */
 		       &si,
 		       &pi);
+
+#ifdef __CYGWIN__
   if (tty >= 0)
     {
       close (tty);
@@ -1843,6 +1870,7 @@ win32_create_inferior (char *exec_file, 
       close (ostdout);
       close (ostderr);
     }
+#endif
 
   if (!ret)
     error (_("Error creating process %s, (error %d)."),
@@ -1951,7 +1979,7 @@ win32_close (int x)
 
 /* Convert pid to printable format. */
 static char *
-cygwin_pid_to_str (ptid_t ptid)
+win32_pid_to_str (ptid_t ptid)
 {
   static char buf[80];
   int pid = PIDGET (ptid);
@@ -2055,7 +2083,7 @@ init_win32_ops (void)
   win32_ops.to_mourn_inferior = win32_mourn_inferior;
   win32_ops.to_can_run = win32_can_run;
   win32_ops.to_thread_alive = win32_win32_thread_alive;
-  win32_ops.to_pid_to_str = cygwin_pid_to_str;
+  win32_ops.to_pid_to_str = win32_pid_to_str;
   win32_ops.to_stop = win32_stop;
   win32_ops.to_stratum = process_stratum;
   win32_ops.to_has_all_memory = 1;
@@ -2086,6 +2114,7 @@ _initialize_win32_nat (void)
 
   add_com_alias ("sharedlibrary", "dll-symbols", class_alias, 1);
 
+#ifdef __CYGWIN__
   add_setshow_boolean_cmd ("shell", class_support, &useshell, _("\
 Set use of shell to start subprocess."), _("\
 Show use of shell to start subprocess."), NULL,
@@ -2099,6 +2128,7 @@ Show whether gdb breaks on exceptions in
 			   NULL,
 			   NULL, /* FIXME: i18n: */
 			   &setlist, &showlist);
+#endif
 
   add_setshow_boolean_cmd ("new-console", class_support, &new_console, _("\
 Set creation of new console when creating child process."), _("\

Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii]

> Date: Tue, 16 Oct 2007 00:31:04 +0100
> From: Pedro Alves <pedro_alves@portugalmail.pt>
> 
> How about the attached?

I have one concern:

> -#include <sys/procfs.h>

Why do you unconditionally remove this include?  Doesn't the Cygwin
build want it?

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Tue, Oct 16, 2007 at 06:12:31AM +0200, Eli Zaretskii wrote:
>> Date: Tue, 16 Oct 2007 00:31:04 +0100
>> From: Pedro Alves <pedro_alves@portugalmail.pt>
>> 
>> How about the attached?
>
>I have one concern:
>
>> -#include <sys/procfs.h>
>
>Why do you unconditionally remove this include?  Doesn't the Cygwin
>build want it?

Actually, I wondered about this too and meant to ask.  I assume that it
isn't really needed?

cgf

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

On 10/16/07, Christopher Faylor wrote:
> On Tue, Oct 16, 2007 at 06:12:31AM +0200, Eli Zaretskii wrote:
> >> Date: Tue, 16 Oct 2007 00:31:04 +0100
> >> From: Pedro Alves <pedro_alves@portugalmail.pt>
> >>
> >> How about the attached?
> >
> >I have one concern:
> >
> >> -#include <sys/procfs.h>
> >
> >Why do you unconditionally remove this include?  Doesn't the Cygwin
> >build want it?
>
> Actually, I wondered about this too and meant to ask.  I assume that it
> isn't really needed?
>

I did explain it upthread:
" - profs.h isn't needed anymore, since I've implemented cygwin cross-core
support a few weeks ago (in i386-cygwin-tdep.c).  The include can be
       unconditionally removed."

The #include was introduced in Egor's original core support patch.

sys/procfs.h:

#ifndef _SYS_PROCFS_H
#define _SYS_PROCFS_H

#include <cygwin/core_dump.h>

#endif /* _SYS_PROCFS_H */

cygwin/core_dump.h describes the structures used in Cygwin core files.

Gdb doesn't use them anymore.  Instead the structures are read in
host-independent form in i386-cygwin-tdep.c:core_process_module_section.

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii]

> Date: Tue, 16 Oct 2007 08:53:10 +0100
> From: "Pedro Alves" <pedro_alves@portugalmail.pt>
> 
> I did explain it upthread:

Sorry I missed that.

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Tue, Oct 16, 2007 at 08:53:10AM +0100, Pedro Alves wrote:
>On 10/16/07, Christopher Faylor wrote:
>> On Tue, Oct 16, 2007 at 06:12:31AM +0200, Eli Zaretskii wrote:
>> >> Date: Tue, 16 Oct 2007 00:31:04 +0100
>> >> From: Pedro Alves <pedro_alves@portugalmail.pt>
>> >>
>> >> How about the attached?
>> >
>> >I have one concern:
>> >
>> >> -#include <sys/procfs.h>
>> >
>> >Why do you unconditionally remove this include?  Doesn't the Cygwin
>> >build want it?
>>
>> Actually, I wondered about this too and meant to ask.  I assume that it
>> isn't really needed?
>>
>
>I did explain it upthread:
>" - profs.h isn't needed anymore, since I've implemented cygwin cross-core
>support a few weeks ago (in i386-cygwin-tdep.c).  The include can be
>       unconditionally removed."

Oops.  I missed that.  Sorry.  Thanks for the (re)explanation.

I approve this patch.

cgf

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Christopher Faylor wrote:
> I approve this patch.
>

Great!  Thank you very much.

> 	* config/i386/mingw.mh, config/i386/mingw.mt: New files.
> 	
> 	* configure.tgt	(i[34567]86-*-mingw32*): Set gdb_target = mingw.

Could someone review these hunks?

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Daniel Jacobowitz]

On Tue, Oct 16, 2007 at 03:35:33PM +0100, Pedro Alves wrote:
> Christopher Faylor wrote:
> > I approve this patch.
> >
> 
> Great!  Thank you very much.
> 
> > 	* config/i386/mingw.mh, config/i386/mingw.mt: New files.
> > 	
> > 	* configure.tgt	(i[34567]86-*-mingw32*): Set gdb_target = mingw.
> 
> Could someone review these hunks?

Chris's approval is good enough for me, and they look fine.

I demand a NEWS entry, though :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Tue, Oct 16, 2007 at 10:41:31AM -0400, Daniel Jacobowitz wrote:
>On Tue, Oct 16, 2007 at 03:35:33PM +0100, Pedro Alves wrote:
>> Christopher Faylor wrote:
>> > I approve this patch.
>> >
>> 
>> Great!  Thank you very much.
>> 
>> > 	* config/i386/mingw.mh, config/i386/mingw.mt: New files.
>> > 	
>> > 	* configure.tgt	(i[34567]86-*-mingw32*): Set gdb_target = mingw.
>> 
>> Could someone review these hunks?
>
>Chris's approval is good enough for me, and they look fine.
>
>I demand a NEWS entry, though :-)

I think that's a good idea too but does this really get us to full MinGW
support?

cgf

Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii]

> Date: Tue, 16 Oct 2007 11:56:24 -0400
> From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
> 
> >I demand a NEWS entry, though :-)
> 
> I think that's a good idea too but does this really get us to full MinGW
> support?

I agree: if MinGW support is incomplete, let's defer the NEWS entry
until it is.

Re: Support of gdb for Windows 64 native systems

[Joel Brobecker]

> > I think that's a good idea too but does this really get us to full MinGW
> > support?
> 
> I agree: if MinGW support is incomplete, let's defer the NEWS entry
> until it is.

I will double-check this when I get a chance, but I think the current
patches should provide relatively complete support. From what I could
tell, the "attach" feature might not be working (apparently, we need
to define the "ATTACH_NO_WAIT" macro), and we have to implement IO
redirection / process creation through a shell. I think these are
the only two major features that we should be missing.

-- 
Joel

Re: Support of gdb for Windows 64 native systems

[Ulrich Weigand]

Joel Brobecker wrote:

> I will double-check this when I get a chance, but I think the current
> patches should provide relatively complete support. From what I could
> tell, the "attach" feature might not be working (apparently, we need
> to define the "ATTACH_NO_WAIT" macro), and we have to implement IO
> redirection / process creation through a shell. I think these are
> the only two major features that we should be missing.

Doesn't Pedro's patch use nm-cygwin.h which defines ATTACH_NO_WAIT?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Ulrich Weigand wrote:
> Joel Brobecker wrote:
> 
>> I will double-check this when I get a chance, but I think the current
>> patches should provide relatively complete support. From what I could
>> tell, the "attach" feature might not be working (apparently, we need
>> to define the "ATTACH_NO_WAIT" macro), and we have to implement IO
>> redirection / process creation through a shell. I think these are
>> the only two major features that we should be missing.
> 

Attaching already works nicelly.

> Doesn't Pedro's patch use nm-cygwin.h which defines ATTACH_NO_WAIT?
> 

Yep.

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Joel Brobecker]

> >>I will double-check this when I get a chance, but I think the current
> >>patches should provide relatively complete support. From what I could
> >>tell, the "attach" feature might not be working (apparently, we need
> >>to define the "ATTACH_NO_WAIT" macro), and we have to implement IO
> >>redirection / process creation through a shell. I think these are
> >>the only two major features that we should be missing.
> >
> 
> Attaching already works nicelly.

Since you've played with the resulting debugger, how would you
categorize the current support? I think it's good enough for
a NEWS entry already.

Do you know of anything else that's missing except using a shell
to do the process creation (which will also allow us to do IO
redirection)?

-- 
Joel

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Joel Brobecker write:
>>>> I will double-check this when I get a chance, but I think the current
>>>> patches should provide relatively complete support. From what I could
>>>> tell, the "attach" feature might not be working (apparently, we need
>>>> to define the "ATTACH_NO_WAIT" macro), and we have to implement IO
>>>> redirection / process creation through a shell. I think these are
>>>> the only two major features that we should be missing.
>> Attaching already works nicelly.
> 
> Since you've played with the resulting debugger, how would you
> categorize the current support? I think it's good enough for
> a NEWS entry already.
> 

Admitelly, I didn't didn't do anything with it besides playing with
it, no serious debugging.
I didn't notice anything lacking, so for me it's good enough.
I quickly tried running the testsuite on it, but for some reason
it refused to work.  So I tried unload.exp manually, and confirmed
that I could step into a dll.

> Do you know of anything else that's missing ...

No, my itch is gone for now :) (but it may come back).

> ... except using a shell
> to do the process creation (which will also allow us to do IO
> redirection)?
> 

I don't think talking about a (unix) shell in a native
Windows gdb makes sense, and I don't know if running through
'cmd /c' has the wanted effect.

There's these 'HANDLE hStdInput, hStdOutput, hStdError' in
STARTUPINFO which may be passed into the CreateProcess call to
redirect io.  Yet another way is to use GetStdHandle/SetStdHandle
much like one uses dup2 on unix.  In both these alternatives
we'll have to do args processing (<,>, etc) ourselves.

But, is this considered a basic feature?  I seldom use it myself.
I don't think it is a show stopper.

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii]

> Date: Wed, 17 Oct 2007 22:59:47 +0100
> From: Pedro Alves <pedro_alves@portugalmail.pt>
> CC: Ulrich Weigand <uweigand@de.ibm.com>, Eli Zaretskii <eliz@gnu.org>, 
>  gdb-patches@sourceware.org
> 
> There's these 'HANDLE hStdInput, hStdOutput, hStdError' in
> STARTUPINFO which may be passed into the CreateProcess call to
> redirect io.  Yet another way is to use GetStdHandle/SetStdHandle
> much like one uses dup2 on unix.  In both these alternatives
> we'll have to do args processing (<,>, etc) ourselves.

I agree that we should do it by redirecting handles directly, not
through the shell.

> But, is this considered a basic feature?  I seldom use it myself.
> I don't think it is a show stopper.

I don't think it's a show-stopper, just a (temporary) lack of feature.
For example, the DJGPP port was part of GDB for years before
redirection support was added.

Re: Support of gdb for Windows 64 native systems

[Joel Brobecker]

> I agree that we should do it by redirecting handles directly, not
> through the shell.

I love the fact that we know where we're going :)

> > But, is this considered a basic feature?  I seldom use it myself.
> > I don't think it is a show stopper.
> 
> I don't think it's a show-stopper, just a (temporary) lack of feature.
> For example, the DJGPP port was part of GDB for years before
> redirection support was added.

If noone gets to it, I will probably implement it under the guidance
of someone who knows Windows well. Argument passing as well as IO
redirections are features that we use regularly (and that we test
too!). As soon as I'm done with my current project (vxWorks!).

-- 
Joel

Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii]

> Date: Wed, 17 Oct 2007 21:16:29 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Pedro Alves <pedro_alves@portugalmail.pt>, uweigand@de.ibm.com,
> 	gdb-patches@sourceware.org
> 
> > I don't think it's a show-stopper, just a (temporary) lack of feature.
> > For example, the DJGPP port was part of GDB for years before
> > redirection support was added.
> 
> If noone gets to it, I will probably implement it under the guidance
> of someone who knows Windows well.

Thanks, I will certainly try to help you, even if I cannot claim to
"know Windows well".

One idea, which I implemented for the DJGPP port years ago, is here:

    http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/debug/common/dbgredir.c?rev=1.3

You can see how these routines are used in go32-nat.c.  Note that some
of the stuff in dbgredir.c is not needed for the Windows port: those
are redir_to_child and redir_to_debugger, with all their subroutines.
(The DJGPP port uses them because there GDB and the inferior run in
the same process, so they share the file handles.)

For Windows, I guess passing the redirected handles through the
STARTUPINFO structure of the CreateProcess call, as suggested by
Pedro, would be more than adequate.

Re: Support of gdb for Windows 64 native systems

[Joel Brobecker]

> Thanks, I will certainly try to help you, even if I cannot claim to
> "know Windows well".

You certainly qualify in my opinion, but if you really insist in using
accurate semantics, I'll rephrase and say "knows Windows better than
I do" ;-).

> One idea, which I implemented for the DJGPP port years ago, is here:
> 
>     http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/debug/common/dbgredir.c?rev=1.3
> 
> You can see how these routines are used in go32-nat.c.  Note that some
> of the stuff in dbgredir.c is not needed for the Windows port: those
> are redir_to_child and redir_to_debugger, with all their subroutines.
> (The DJGPP port uses them because there GDB and the inferior run in
> the same process, so they share the file handles.)

Wow, it's the first time that I see the debugger and the inferior
share the same process. I know of a Windows application that embeds
its own debug stub to allow certain threads to remain active when
the rest of the inferior is stopped, though...

> For Windows, I guess passing the redirected handles through the
> STARTUPINFO structure of the CreateProcess call, as suggested by
> Pedro, would be more than adequate.

OK - Thanks for the advice. I'm hoping to find some time in the next
few weeks, hopefully before christmas. Hopefully we can give ourselves
a nice unexpected present :). (I didn't expect MinGW support to go in
so fast - kudos to Pedro and thanks to Chris and yourself).

-- 
Joel

Re: Support of gdb for Windows 64 native systems

[Daniel Jacobowitz]

On Thu, Oct 18, 2007 at 09:19:50PM -0700, Joel Brobecker wrote:
> OK - Thanks for the advice. I'm hoping to find some time in the next
> few weeks, hopefully before christmas. Hopefully we can give ourselves
> a nice unexpected present :). (I didn't expect MinGW support to go in
> so fast - kudos to Pedro and thanks to Chris and yourself).

Either way, may I suggest that NEWS entry again?  It would be good to
support redirection, but it's worth announcing the port either way.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii]

> Date: Fri, 19 Oct 2007 07:53:59 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, pedro_alves@portugalmail.pt,
> 	uweigand@de.ibm.com, gdb-patches@sourceware.org
> 
> Either way, may I suggest that NEWS entry again?  It would be good to
> support redirection, but it's worth announcing the port either way.

I agree.

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Daniel Jacobowitz wrote:
> Chris's approval is good enough for me, and they look fine.
> 

I've checked it in.

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Christopher Faylor wrote:
> On Sun, Oct 14, 2007 at 07:02:26PM +0100, Pedro Alves wrote:
>> Christopher Faylor wrote:
>>>> +  flags = DEBUG_ONLY_THIS_PROCESS;
>>>> +  toexec = exec_file;
>>> This doesn't seem right.  You moved this setting outside of an if block
>>> and didn't accommodate the else condition.
>> I didn't move it.  The if inside the __CYGWIN__ block sets TOEXEC in both
>> branches.
> 
> I'm talking about "flags".
> 

Sorry, should have realized it.

Maybe I'm too tired, but I really can't see what's <logically> not
right :(

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Mon, Oct 15, 2007 at 12:14:01AM +0100, Pedro Alves wrote:
> Christopher Faylor wrote:
>> On Sun, Oct 14, 2007 at 07:02:26PM +0100, Pedro Alves wrote:
>>> Christopher Faylor wrote:
>>>>> +  flags = DEBUG_ONLY_THIS_PROCESS;
>>>>> +  toexec = exec_file;
>>>> This doesn't seem right.  You moved this setting outside of an if block
>>>> and didn't accommodate the else condition.
>>> I didn't move it.  The if inside the __CYGWIN__ block sets TOEXEC in both
>>> branches.
>> I'm talking about "flags".
>
> Sorry, should have realized it.
>
> Maybe I'm too tired, but I really can't see what's <logically> not
> right :(

You took a 'flags = ' out of the first part of an if/else block and put
it before the if block.  Doesn't that seem wrong?

cgf

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Christopher Faylor wrote:
> 
> You took a 'flags = ' out of the first part of an if/else block and put
> it before the if block.  Doesn't that seem wrong?

Shame on me.  I should sleep more often  :(

I stared at it for long, but still somehow missed the
fact that the first branch of the 'if' is negated ...

This is what I should have written:

#ifdef __CYGWIN__
   if (!useshell)
     {
       cygwin_conv_to_win32_path (exec_file, real_path);
       toexec = real_path;
       flags = DEBUG_ONLY_THIS_PROCESS;
     }
   else
     {
       char *newallargs;
       sh = getenv ("SHELL");
       if (!sh)
	sh = "/bin/sh";
       cygwin_conv_to_win32_path (sh, shell);
       newallargs = alloca (sizeof (" -c 'exec  '") + strlen (exec_file)
			   + strlen (allargs) + 2);
       sprintf (newallargs, " -c 'exec %s %s'", exec_file, allargs);
       allargs = newallargs;
       toexec = shell;
       flags = DEBUG_PROCESS;
     }
#else
   toexec = exec_file;
   flags = DEBUG_ONLY_THIS_PROCESS;
#endif

Thanks for your patience.

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Joel Brobecker]

[moved to gdb-patches as well]

> What's done:
> 
> 	- Added mingw.mh, mingw.mt as copies from the cygwin files.
> 	- Updated configure.tgt to set gdb_target.
> 	- Disabled cygwin specific functionality in win32-nat.c.  As can
> 	be seen, the changes are very small.
> 	- profs.h isn't needed anymore, since I've implemented cygwin 
> 	cross-core support a few weeks ago (in i386-cygwin-tdep.c).
>       The include can be unconditionally removed.

Nice!

> What's next:
> 
> 	Test with a mingw built libexpat to test dll support.

Done. Seems to be working well:

    (top-gdb) info dll
    From        To          Syms Read   Shared Object Library
    0x7c901000  0x7c9afe88  Yes         C:\WINDOWS\system32\ntdll.dll
    0x7c801000  0x7c8f4bec  Yes         C:\WINDOWS\system32\kernel32.dll
    0x77c11000  0x77c67d74  Yes         C:\WINDOWS\system32\msvcrt.dll
    0x7e411000  0x7e49fde8  Yes         C:\WINDOWS\system32\user32.dll
    0x77f11000  0x77f568a0  Yes         C:\WINDOWS\system32\gdi32.dll
    0x71ab1000  0x71ac6dc8  Yes         C:\WINDOWS\system32\ws2_32.dll
    0x71aa1000  0x71aa7324  Yes         C:\WINDOWS\system32\ws2help.dll
    0x77dd1000  0x77e6ab38  Yes         C:\WINDOWS\system32\advapi32.dll
    0x77e71000  0x77f003f8  Yes         C:\WINDOWS\system32\rpcrt4.dll

> 	Rename a few things, which really aren't cygwin specific, like:
> 		* cygwin_get_dr6 -> win32_get_dr6
> 		* i386-cygwin-tdep.h -> i386-win32-tdep.h
> 		* nm-cygwin.h -> nm-cygming.h

I propose we use "windows" instead of either "win32" or "cygming".
It seems more descriptive to me, and also avoids the "32", since
eventually we might want to add support for 64-bit windows....

-- 
Joel

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Sun, Oct 14, 2007 at 01:32:45PM -0700, Joel Brobecker wrote:
>[moved to gdb-patches as well]
>
>> What's done:
>> 
>> 	- Added mingw.mh, mingw.mt as copies from the cygwin files.
>> 	- Updated configure.tgt to set gdb_target.
>> 	- Disabled cygwin specific functionality in win32-nat.c.  As can
>> 	be seen, the changes are very small.
>> 	- profs.h isn't needed anymore, since I've implemented cygwin 
>> 	cross-core support a few weeks ago (in i386-cygwin-tdep.c).
>>       The include can be unconditionally removed.
>
>Nice!
>
>> What's next:
>> 
>> 	Test with a mingw built libexpat to test dll support.
>
>Done. Seems to be working well:
>
>    (top-gdb) info dll
>    From        To          Syms Read   Shared Object Library
>    0x7c901000  0x7c9afe88  Yes         C:\WINDOWS\system32\ntdll.dll
>    0x7c801000  0x7c8f4bec  Yes         C:\WINDOWS\system32\kernel32.dll
>    0x77c11000  0x77c67d74  Yes         C:\WINDOWS\system32\msvcrt.dll
>    0x7e411000  0x7e49fde8  Yes         C:\WINDOWS\system32\user32.dll
>    0x77f11000  0x77f568a0  Yes         C:\WINDOWS\system32\gdi32.dll
>    0x71ab1000  0x71ac6dc8  Yes         C:\WINDOWS\system32\ws2_32.dll
>    0x71aa1000  0x71aa7324  Yes         C:\WINDOWS\system32\ws2help.dll
>    0x77dd1000  0x77e6ab38  Yes         C:\WINDOWS\system32\advapi32.dll
>    0x77e71000  0x77f003f8  Yes         C:\WINDOWS\system32\rpcrt4.dll
>
>> 	Rename a few things, which really aren't cygwin specific, like:
>> 		* cygwin_get_dr6 -> win32_get_dr6
>> 		* i386-cygwin-tdep.h -> i386-win32-tdep.h
>> 		* nm-cygwin.h -> nm-cygming.h
>
>I propose we use "windows" instead of either "win32" or "cygming".
>It seems more descriptive to me, and also avoids the "32", since
>eventually we might want to add support for 64-bit windows....

I don't really care about this but the "cygming" probably comes from
similar naming in gcc.

I believe that RMS has objections to the name "win32" and "win64", too.
So, whatever we use, it shouldn't have the abbreviation "win" in it.

cgf

Re: Support of gdb for Windows 64 native systems

[Pedro Alves]

Christopher Faylor wrote:

>>> 	Rename a few things, which really aren't cygwin specific, like:
>>> 		* cygwin_get_dr6 -> win32_get_dr6
>>> 		* i386-cygwin-tdep.h -> i386-win32-tdep.h
>>> 		* nm-cygwin.h -> nm-cygming.h
>> I propose we use "windows" instead of either "win32" or "cygming".
>> It seems more descriptive to me, and also avoids the "32", since
>> eventually we might want to add support for 64-bit windows....
> 

We better decide if and what to rename them the next time we're
changing them, then.

> I don't really care about this but the "cygming" probably comes from
> similar naming in gcc.
> 

Yes.

> I believe that RMS has objections to the name "win32" and "win64", too.
> So, whatever we use, it shouldn't have the abbreviation "win" in it.
> 

I thought his objections were about the naming of the operation
system.  win32 seems right to me, when we're talking about the
Win32 API.  Windows includes other things, like the interix
subsystem, or the NT native API.

Either way, it might seem I was implying it, but you won't see
rename-only patches from me :)

Cheers,
Pedro Alves

Re: Support of gdb for Windows 64 native systems

[Christopher Faylor]

On Mon, Oct 15, 2007 at 12:28:30AM +0100, Pedro Alves wrote:
> Christopher Faylor wrote:
>
>>>> 	Rename a few things, which really aren't cygwin specific, like:
>>>> 		* cygwin_get_dr6 -> win32_get_dr6
>>>> 		* i386-cygwin-tdep.h -> i386-win32-tdep.h
>>>> 		* nm-cygwin.h -> nm-cygming.h
>>> I propose we use "windows" instead of either "win32" or "cygming".
>>> It seems more descriptive to me, and also avoids the "32", since
>>> eventually we might want to add support for 64-bit windows....
>
> We better decide if and what to rename them the next time we're
> changing them, then.
>
>> I don't really care about this but the "cygming" probably comes from
>> similar naming in gcc.
>
> Yes.

FWIW, I think either I or Danny Smith and I came up with that naming
over there.

>> I believe that RMS has objections to the name "win32" and "win64", too.
>> So, whatever we use, it shouldn't have the abbreviation "win" in it.
>
> I thought his objections were about the naming of the operation
> system.  win32 seems right to me, when we're talking about the
> Win32 API.  Windows includes other things, like the interix
> subsystem, or the NT native API.

I didn't think he cared.  He used to send me email when I was
maintaining the --win32 make option in Cygwin but that does, I guess,
imply the OS rather than the API.  I think win32 and win64 make sense
but I thought I should mention this nonetheless.

cgf