Re: [RFC] Mingw Windows 64-bit gdbserver

Re: [RFC] Mingw Windows 64-bit gdbserver

[Ozkan Sezer]

>> +  x86_64-w64-mingw*)<->srv_regobj="$srv_amd64_regobj"

It would be better if this is changed to x86_64-*-mingw*
because, although not recommended, mingw-w64 can be configured
for x86_64-pc-mingw32, too.

>>  - About the used communication library:
>>   -lwsock32 was not found by the mingw, but main gdb

-lwsock32 is available for win64 in recent versions of mingw-w64, but...

>> doesn't seem to use it, should we move to ws2_32 for both win32 and win64?
>
> Don't we need to make gdbserver include windows2.h instead of winsock.h too?

s/windows2.h/winsock2.h/
such change would be the logical thing to do considering gdb
itself being linked to ws2_32.

--
Ozkan

[RFC] Mingw Windows 64-bit gdbserver

[Pierre Muller]

  This patch tries to implement support for 
gdbserver on Windows 64-bit, using the mingw32
cross compiler to windows-64bit.

  I am unsure if anyone else already tried this,
but searching in gdb-patches I didn't find anything...
Don't hesitate to tell me otherwise...

  The resulting gdbserver seem usable to me,

  I do have a few questions:
  - About the new file, win64-amd64-low.c
should I remove the copyright years and only leave 2010?
should I state that it is adapted from win32-i386-low.c?

 - About gdbserver/configure regeneration:
this added several lines:
+/* Needed for new procfs interface on sparc-solaris.  */
+#define _STRUCTURED_PROC 1
  I did use autoconf version 2.64 as required...
Is this normal?

 - About the used communication library:
  -lwsock32 was not found by the mingw, but main gdb
doesn't seem to use it, should we move to ws2_32 for both win32 and win64?

  I still do have a problem when I connect
to win64 gdbserver from a multi target win32 gdb executable,
somehow, the library list does not seem to correctly 
read in the library addresses... Still investigating this.
It seems related to the fact that I do not have 
local copies of my remote DLLs.

Final question:
  Does that patch deserve a documentation or NEWS entry?


Pierre Muller
Pascal language support maintainer for GDB


2010-04-16  Pierre Muller  <muller@ics.u-strasbg.fr>

	* configure.tgt (x86_64-*-mingw*): Set BUILD_GDBSERVER to yes.

gdbserver ChangeLog entry:

2010-04-16  Pierre Muller  <muller@ics.u-strasbg.fr>

	* configure.srv (srv_amd64_regobj): Replace "x86_64-avx.o"
	by "amd64-avx.o".
	(x86_64-*-mingw*): New configuration for Windows 64bit OS.
	Set srv_mingw64 variable to `yes'.
	* configure.ac: Use `ws2_32' library for mingw64 instead of
`wsock32'.
	* configure: Regenerated.
	* win32-low.c: Use uintptr_t type to store
	addresses for both 32bit and 64bit binaries.
	(child_xfer_memory): Use uintptr_t type for local variable `addr'.
	(get_image_name): Use uintptr_t for local variable `done'.
	(psapi_get_dll_name): Use uintptr_t type for parameter
`BaseAddress'.
	(toolhelp_get_dll_name): Idem.
	(handle_load_dll): Use uintptr_t type for local variable
`load_addr'.
	(handle_unload_dll): Use unitptr_t typecast to avoid warning.
	(handle_exception): Use phex_nz to avoid warning.
	(win32_wait): Remove unused local variable `process'.
	* win64-amd64-low.c: New file adapted from win32-i386-low.c.


Index: configure.tgt
===================================================================
RCS file: /cvs/src/src/gdb/configure.tgt,v
retrieving revision 1.230
diff -u -p -r1.230 configure.tgt
--- configure.tgt	25 Feb 2010 20:30:58 -0000	1.230
+++ configure.tgt	16 Apr 2010 14:32:54 -0000
@@ -590,6 +590,7 @@ x86_64-*-mingw*)
 	gdb_target_obs="amd64-tdep.o amd64-windows-tdep.o \
                         i386-tdep.o i386-cygwin-tdep.o i387-tdep.o \
                         solib-target.o windows-tdep.o"
+	build_gdbserver=yes
         ;;
 x86_64-*-netbsd* | x86_64-*-knetbsd*-gnu)
 	# Target: NetBSD/amd64
Index: gdbserver/configure
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/configure,v
retrieving revision 1.46
diff -u -p -r1.46 configure
--- gdbserver/configure	23 Feb 2010 19:16:16 -0000	1.46
+++ gdbserver/configure	16 Apr 2010 14:32:55 -0000
@@ -4055,6 +4055,8 @@ esac
 
 if test "${srv_mingwce}" = "yes"; then
   LIBS="$LIBS -lws2"
+elif test "${srv_mingw64}" = "yes"; then
+  LIBS="$LIBS -lws2_32"
 elif test "${srv_mingw}" = "yes"; then
   LIBS="$LIBS -lwsock32"
 elif test "${srv_qnx}" = "yes"; then
@@ -4153,6 +4155,8 @@ else
 /* end confdefs.h.  */
 
 #define _SYSCALL32
+/* Needed for new procfs interface on sparc-solaris.  */
+#define _STRUCTURED_PROC 1
 #include <sys/procfs.h>
 int
 main ()
@@ -4188,6 +4192,8 @@ else
 /* end confdefs.h.  */
 
 #define _SYSCALL32
+/* Needed for new procfs interface on sparc-solaris.  */
+#define _STRUCTURED_PROC 1
 #include <sys/procfs.h>
 int
 main ()
@@ -4223,6 +4229,8 @@ else
 /* end confdefs.h.  */
 
 #define _SYSCALL32
+/* Needed for new procfs interface on sparc-solaris.  */
+#define _STRUCTURED_PROC 1
 #include <sys/procfs.h>
 int
 main ()
@@ -4258,6 +4266,8 @@ else
 /* end confdefs.h.  */
 
 #define _SYSCALL32
+/* Needed for new procfs interface on sparc-solaris.  */
+#define _STRUCTURED_PROC 1
 #include <sys/procfs.h>
 int
 main ()
Index: gdbserver/configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/configure.ac,v
retrieving revision 1.33
diff -u -p -r1.33 configure.ac
--- gdbserver/configure.ac	23 Feb 2010 19:16:16 -0000	1.33
+++ gdbserver/configure.ac	16 Apr 2010 14:32:55 -0000
@@ -117,6 +117,8 @@ esac
 
 if test "${srv_mingwce}" = "yes"; then
   LIBS="$LIBS -lws2"
+elif test "${srv_mingw64}" = "yes"; then
+  LIBS="$LIBS -lws2_32"
 elif test "${srv_mingw}" = "yes"; then
   LIBS="$LIBS -lwsock32"
 elif test "${srv_qnx}" = "yes"; then
Index: gdbserver/configure.srv
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/configure.srv,v
retrieving revision 1.53
diff -u -p -r1.53 configure.srv
--- gdbserver/configure.srv	8 Apr 2010 22:32:38 -0000	1.53
+++ gdbserver/configure.srv	16 Apr 2010 14:32:55 -0000
@@ -24,7 +24,7 @@ srv_hostio_err_objs="hostio-errno.o"
 
 srv_i386_regobj="i386.o i386-avx.o i386-mmx.o"
 srv_i386_linux_regobj="i386-linux.o i386-avx-linux.o i386-mmx-linux.o"
-srv_amd64_regobj="amd64.o x86-64-avx.o"
+srv_amd64_regobj="amd64.o amd64-avx.o"
 srv_amd64_linux_regobj="amd64-linux.o amd64-avx-linux.o"
 
 srv_i386_32bit_xmlfiles="i386/32bit-core.xml i386/32bit-sse.xml
i386/32bit-avx.xml"
@@ -231,6 +231,13 @@ case "${target}" in
 			srv_linux_regsets=yes
 			srv_linux_thread_db=yes
 			;;
+  x86_64-w64-mingw*)	srv_regobj="$srv_amd64_regobj"
+			srv_tgtobj="i386-low.o i387-fp.o win32-low.o
win64-amd64-low.o"
+			srv_xmlfiles="$srv_i386_xmlfiles
$srv_amd64_xmlfiles"
+			srv_mingw64=yes
+			srv_mingw=yes
+			;;
+
   xscale*-*-linux*)	srv_regobj=reg-arm.o
 			srv_tgtobj="linux-low.o linux-arm-low.o"
 			srv_linux_usrregs=yes
Index: gdbserver/win32-low.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/win32-low.c,v
retrieving revision 1.46
diff -u -p -r1.46 win32-low.c
--- gdbserver/win32-low.c	16 Apr 2010 07:49:37 -0000	1.46
+++ gdbserver/win32-low.c	16 Apr 2010 14:32:55 -0000
@@ -280,7 +280,7 @@ child_xfer_memory (CORE_ADDR memaddr, ch
 		   int write, struct target_ops *target)
 {
   SIZE_T done;
-  long addr = (long) memaddr;
+  uintptr_t addr = (uintptr_t) memaddr;
 
   if (write)
     {
@@ -941,7 +941,7 @@ get_image_name (HANDLE h, void *address,
   char *address_ptr;
   int len = 0;
   char b[2];
-  DWORD done;
+  uintptr_t done;
 
   /* Attempt to read the name of the dll that was detected.
      This is documented to work only when actively debugging
@@ -1019,7 +1019,7 @@ load_psapi (void)
 }
 
 static int
-psapi_get_dll_name (DWORD BaseAddress, char *dll_name_ret)
+psapi_get_dll_name (uintptr_t BaseAddress, char *dll_name_ret)
 {
   DWORD len;
   MODULEINFO mi;
@@ -1064,7 +1064,7 @@ psapi_get_dll_name (DWORD BaseAddress, c
 		 (int) err, strwinerror (err));
 	}
 
-      if ((DWORD) (mi.lpBaseOfDll) == BaseAddress)
+      if ((uintptr_t) (mi.lpBaseOfDll) == BaseAddress)
 	{
 	  len = (*win32_GetModuleFileNameExA) (current_process_handle,
 					       DllHandle[i],
@@ -1134,7 +1134,7 @@ load_toolhelp (void)
 }
 
 static int
-toolhelp_get_dll_name (DWORD BaseAddress, char *dll_name_ret)
+toolhelp_get_dll_name (uintptr_t BaseAddress, char *dll_name_ret)
 {
   HANDLE snapshot_module;
   MODULEENTRY32 modEntry = { sizeof (MODULEENTRY32) };
@@ -1151,7 +1151,7 @@ toolhelp_get_dll_name (DWORD BaseAddress
   /* Ignore the first module, which is the exe.  */
   if (win32_Module32First (snapshot_module, &modEntry))
     while (win32_Module32Next (snapshot_module, &modEntry))
-      if ((DWORD) modEntry.modBaseAddr == BaseAddress)
+      if ((uintptr_t) modEntry.modBaseAddr == BaseAddress)
 	{
 #ifdef UNICODE
 	  wcstombs (dll_name_ret, modEntry.szExePath, MAX_PATH + 1);
@@ -1176,21 +1176,21 @@ handle_load_dll (void)
   LOAD_DLL_DEBUG_INFO *event = &current_event.u.LoadDll;
   char dll_buf[MAX_PATH + 1];
   char *dll_name = NULL;
-  DWORD load_addr;
+  uintptr_t load_addr;
 
   dll_buf[0] = dll_buf[sizeof (dll_buf) - 1] = '\0';
 
   /* Windows does not report the image name of the dlls in the debug
      event on attaches.  We resort to iterating over the list of
      loaded dlls looking for a match by image base.  */
-  if (!psapi_get_dll_name ((DWORD) event->lpBaseOfDll, dll_buf))
+  if (!psapi_get_dll_name ((uintptr_t) event->lpBaseOfDll, dll_buf))
     {
       if (!server_waiting)
 	/* On some versions of Windows and Windows CE, we can't create
 	   toolhelp snapshots while the inferior is stopped in a
 	   LOAD_DLL_DEBUG_EVENT due to a dll load, but we can while
 	   Windows is reporting the already loaded dlls.  */
-	toolhelp_get_dll_name ((DWORD) event->lpBaseOfDll, dll_buf);
+	toolhelp_get_dll_name ((uintptr_t) event->lpBaseOfDll, dll_buf);
     }
 
   dll_name = dll_buf;
@@ -1205,7 +1205,7 @@ handle_load_dll (void)
      the offset from 0 of the first byte in an image - because
      of the file header and the section alignment. */
 
-  load_addr = (DWORD) event->lpBaseOfDll + 0x1000;
+  load_addr = (uintptr_t) event->lpBaseOfDll + 0x1000;
   win32_add_one_solib (dll_name, load_addr);
 }
 
@@ -1213,7 +1213,7 @@ static void
 handle_unload_dll (void)
 {
   CORE_ADDR load_addr =
-	  (CORE_ADDR) (DWORD) current_event.u.UnloadDll.lpBaseOfDll;
+	  (CORE_ADDR) (uintptr_t) current_event.u.UnloadDll.lpBaseOfDll;
   load_addr += 0x1000;
   unloaded_dll (NULL, load_addr);
 }
@@ -1314,10 +1314,10 @@ handle_exception (struct target_waitstat
 	  ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
 	  return;
 	}
-      OUTMSG2 (("gdbserver: unknown target exception 0x%08lx at 0x%08lx",
+      OUTMSG2 (("gdbserver: unknown target exception 0x%08lx at 0x%s",
 		current_event.u.Exception.ExceptionRecord.ExceptionCode,
-		(DWORD) current_event.u.Exception.ExceptionRecord.
-		ExceptionAddress));
+		phex_nz ((uintptr_t)
current_event.u.Exception.ExceptionRecord.
+		ExceptionAddress, sizeof(uintptr_t))));
       ourstatus->value.sig = TARGET_SIGNAL_UNKNOWN;
       break;
     }
@@ -1577,7 +1577,6 @@ get_child_debug_event (struct target_wai
 static ptid_t
 win32_wait (ptid_t ptid, struct target_waitstatus *ourstatus, int options)
 {
-  struct process_info *process;
   struct regcache *regcache;
 
   while (1)
Index: gdbserver/win64-amd64-low.c
===================================================================
RCS file: gdbserver/win64-amd64-low.c
diff -N gdbserver/win64-amd64-low.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdbserver/win64-amd64-low.c	16 Apr 2010 14:32:55 -0000
@@ -0,0 +1,343 @@
+/* Copyright (C) 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/
+
+#include "server.h"
+#include "win32-low.h"
+#include "i386-low.h"
+
+#define FCS_REGNUM 27
+#define FOP_REGNUM 31
+
+#define FLAG_TRACE_BIT 0x100
+
+#ifndef CONTEXT_EXTENDED_REGISTERS
+#define CONTEXT_EXTENDED_REGISTERS 0
+#endif
+
+/* Defined in auto-generated file reg-amd64.c.  */
+void init_registers_amd64 (void);
+
+static struct i386_debug_reg_state debug_reg_state;
+
+static int debug_registers_changed = 0;
+static int debug_registers_used = 0;
+
+/* Update the inferior's debug register REGNUM from STATE.  */
+
+void
+i386_dr_low_set_addr (const struct i386_debug_reg_state *state, int regnum)
+{
+  if (! (regnum >= 0 && regnum <= DR_LASTADDR - DR_FIRSTADDR))
+    fatal ("Invalid debug register %d", regnum);
+
+  /* debug_reg_state.dr_mirror is already set.
+     Just notify i386_set_thread_context, i386_thread_added
+     that the registers need to be updated.  */
+  debug_registers_changed = 1;
+  debug_registers_used = 1;
+}
+
+/* Update the inferior's DR7 debug control register from STATE.  */
+
+void
+i386_dr_low_set_control (const struct i386_debug_reg_state *state)
+{
+  /* debug_reg_state.dr_control_mirror is already set.
+     Just notify i386_set_thread_context, i386_thread_added
+     that the registers need to be updated.  */
+  debug_registers_changed = 1;
+  debug_registers_used = 1;
+}
+
+/* Get the value of the DR6 debug status register from the inferior
+   and record it in STATE.  */
+
+void
+i386_dr_low_get_status (struct i386_debug_reg_state *state)
+{
+  /* We don't need to do anything here, the last call to thread_rec for
+     current_event.dwThreadId id has already set it.  */
+}
+
+/* Watchpoint support.  */
+
+static int
+amd64_insert_point (char type, CORE_ADDR addr, int len)
+{
+  switch (type)
+    {
+    case '2':
+    case '3':
+    case '4':
+      return i386_low_insert_watchpoint (&debug_reg_state,
+					 type, addr, len);
+    default:
+      /* Unsupported.  */
+      return 1;
+    }
+}
+
+static int
+amd64_remove_point (char type, CORE_ADDR addr, int len)
+{
+  switch (type)
+    {
+    case '2':
+    case '3':
+    case '4':
+      return i386_low_remove_watchpoint (&debug_reg_state,
+					 type, addr, len);
+    default:
+      /* Unsupported.  */
+      return 1;
+    }
+}
+
+static int
+amd64_stopped_by_watchpoint (void)
+{
+  return i386_low_stopped_by_watchpoint (&debug_reg_state);
+}
+
+static CORE_ADDR
+amd64_stopped_data_address (void)
+{
+  CORE_ADDR addr;
+  if (i386_low_stopped_data_address (&debug_reg_state, &addr))
+    return addr;
+  return 0;
+}
+
+static void
+amd64_initial_stuff (void)
+{
+  i386_low_init_dregs (&debug_reg_state);
+  debug_registers_changed = 0;
+  debug_registers_used = 0;
+}
+
+static void
+amd64_get_thread_context (win32_thread_info *th, DEBUG_EVENT*
current_event)
+{
+  /* Requesting the CONTEXT_EXTENDED_REGISTERS register set fails if
+     the system doesn't support extended registers.  */
+  static DWORD extended_registers = CONTEXT_EXTENDED_REGISTERS;
+
+ again:
+  th->context.ContextFlags = (CONTEXT_FULL
+			      | CONTEXT_FLOATING_POINT
+			      | CONTEXT_DEBUG_REGISTERS
+			      | extended_registers);
+
+  if (!GetThreadContext (th->h, &th->context))
+    {
+      DWORD e = GetLastError ();
+
+      if (extended_registers && e == ERROR_INVALID_PARAMETER)
+	{
+	  extended_registers = 0;
+	  goto again;
+	}
+
+      error ("GetThreadContext failure %ld\n", (long) e);
+    }
+
+  debug_registers_changed = 0;
+
+  if (th->tid == current_event->dwThreadId)
+    {
+      /* Copy dr values from the current thread.  */
+      struct i386_debug_reg_state *dr = &debug_reg_state;
+      dr->dr_mirror[0] = th->context.Dr0;
+      dr->dr_mirror[1] = th->context.Dr1;
+      dr->dr_mirror[2] = th->context.Dr2;
+      dr->dr_mirror[3] = th->context.Dr3;
+      dr->dr_status_mirror = th->context.Dr6;
+      dr->dr_control_mirror = th->context.Dr7;
+    }
+}
+
+static void
+amd64_set_thread_context (win32_thread_info *th, DEBUG_EVENT*
current_event)
+{
+  if (debug_registers_changed)
+    {
+      struct i386_debug_reg_state *dr = &debug_reg_state;
+      th->context.Dr0 = dr->dr_mirror[0];
+      th->context.Dr1 = dr->dr_mirror[1];
+      th->context.Dr2 = dr->dr_mirror[2];
+      th->context.Dr3 = dr->dr_mirror[3];
+      /* th->context.Dr6 = dr->dr_status_mirror;
+	 FIXME: should we set dr6 also ?? */
+      th->context.Dr7 = dr->dr_control_mirror;
+    }
+
+  SetThreadContext (th->h, &th->context);
+}
+
+static void
+amd64_thread_added (win32_thread_info *th)
+{
+  /* Set the debug registers for the new thread if they are used.  */
+  if (debug_registers_used)
+    {
+      struct i386_debug_reg_state *dr = &debug_reg_state;
+      th->context.ContextFlags = CONTEXT_DEBUG_REGISTERS;
+      GetThreadContext (th->h, &th->context);
+
+      th->context.Dr0 = dr->dr_mirror[0];
+      th->context.Dr1 = dr->dr_mirror[1];
+      th->context.Dr2 = dr->dr_mirror[2];
+      th->context.Dr3 = dr->dr_mirror[3];
+      /* th->context.Dr6 = dr->dr_status_mirror;
+	 FIXME: should we set dr6 also ?? */
+      th->context.Dr7 = dr->dr_control_mirror;
+
+      SetThreadContext (th->h, &th->context);
+      th->context.ContextFlags = 0;
+    }
+}
+
+static void
+amd64_single_step (win32_thread_info *th)
+{
+  th->context.EFlags |= FLAG_TRACE_BIT;
+}
+
+/* An array of offset mappings into a Win64 Context structure.
+   This is a one-to-one mapping which is indexed by gdb's register
+   numbers.  It retrieves an offset into the context structure where
+   the register is located.
+   An offset value of -1 indicates that Win64 does not provide this
+   register in it's CONTEXT structure.  In this case regptr will return
+   a pointer into a dummy register.  */
+#define context_offset(x) (offsetof (CONTEXT, x))
+static const int mappings[] =
+{
+  context_offset (Rax),
+  context_offset (Rbx),
+  context_offset (Rcx),
+  context_offset (Rdx),
+  context_offset (Rsi),
+  context_offset (Rdi),
+  context_offset (Rbp),
+  context_offset (Rsp),
+  context_offset (R8),
+  context_offset (R9),
+  context_offset (R10),
+  context_offset (R11),
+  context_offset (R12),
+  context_offset (R13),
+  context_offset (R14),
+  context_offset (R15),
+  context_offset (Rip),
+  context_offset (EFlags),
+  context_offset (SegCs),
+  context_offset (SegSs),
+  context_offset (SegDs),
+  context_offset (SegEs),
+  context_offset (SegFs),
+  context_offset (SegGs),
+  context_offset (FloatSave.FloatRegisters[0]),
+  context_offset (FloatSave.FloatRegisters[1]),
+  context_offset (FloatSave.FloatRegisters[2]),
+  context_offset (FloatSave.FloatRegisters[3]),
+  context_offset (FloatSave.FloatRegisters[4]),
+  context_offset (FloatSave.FloatRegisters[5]),
+  context_offset (FloatSave.FloatRegisters[6]),
+  context_offset (FloatSave.FloatRegisters[7]),
+  context_offset (FloatSave.ControlWord),
+  context_offset (FloatSave.StatusWord),
+  context_offset (FloatSave.TagWord),
+  context_offset (FloatSave.ErrorSelector),
+  context_offset (FloatSave.ErrorOffset),
+  context_offset (FloatSave.DataSelector),
+  context_offset (FloatSave.DataOffset),
+  context_offset (FloatSave.ErrorSelector)
+  /* XMM0-7 */ ,
+  context_offset (Xmm0),
+  context_offset (Xmm1),
+  context_offset (Xmm2),
+  context_offset (Xmm3),
+  context_offset (Xmm4),
+  context_offset (Xmm5),
+  context_offset (Xmm6),
+  context_offset (Xmm7),
+  context_offset (Xmm8),
+  context_offset (Xmm9),
+  context_offset (Xmm10),
+  context_offset (Xmm11),
+  context_offset (Xmm12),
+  context_offset (Xmm13),
+  context_offset (Xmm14),
+  context_offset (Xmm15),
+  /* MXCSR */
+  context_offset (FloatSave.MxCsr)
+};
+#undef context_offset
+
+/* Fetch register from gdbserver regcache data.  */
+static void
+amd64_fetch_inferior_register (struct regcache *regcache,
+			      win32_thread_info *th, int r)
+{
+  char *context_offset = (char *) &th->context + mappings[r];
+
+  long l;
+  if (r == FCS_REGNUM)
+    {
+      l = *((long *) context_offset) & 0xffff;
+      supply_register (regcache, r, (char *) &l);
+    }
+  else if (r == FOP_REGNUM)
+    {
+      l = (*((long *) context_offset) >> 16) & ((1 << 11) - 1);
+      supply_register (regcache, r, (char *) &l);
+    }
+  else
+    supply_register (regcache, r, context_offset);
+}
+
+/* Store a new register value into the thread context of TH.  */
+static void
+amd64_store_inferior_register (struct regcache *regcache,
+			      win32_thread_info *th, int r)
+{
+  char *context_offset = (char *) &th->context + mappings[r];
+  collect_register (regcache, r, context_offset);
+}
+
+static const unsigned char amd64_win64_breakpoint = 0xcc;
+#define amd64_win64_breakpoint_len 1
+
+struct win32_target_ops the_low_target = {
+  init_registers_amd64,
+  sizeof (mappings) / sizeof (mappings[0]),
+  amd64_initial_stuff,
+  amd64_get_thread_context,
+  amd64_set_thread_context,
+  amd64_thread_added,
+  amd64_fetch_inferior_register,
+  amd64_store_inferior_register,
+  amd64_single_step,
+  &amd64_win64_breakpoint,
+  amd64_win64_breakpoint_len,
+  amd64_insert_point,
+  amd64_remove_point,
+  amd64_stopped_by_watchpoint,
+  amd64_stopped_data_address
+};

Re: [RFC] Mingw Windows 64-bit gdbserver

[Pedro Alves]

On Friday 16 April 2010 16:31:51, Pierre Muller wrote:
>   This patch tries to implement support for 
> gdbserver on Windows 64-bit, using the mingw32
> cross compiler to windows-64bit.
> 
>   I am unsure if anyone else already tried this,
> but searching in gdb-patches I didn't find anything...
> Don't hesitate to tell me otherwise...
> 
>   The resulting gdbserver seem usable to me,
> 
>   I do have a few questions:
>   - About the new file, win64-amd64-low.c
> should I remove the copyright years and only leave 2010?
> should I state that it is adapted from win32-i386-low.c?

How about instead merging the files, like
linux-x86-low.c handles both 64-bit and 32-bit?  There's
a lot of common stuff between both archs support, it
seems.  Also, is there any debug API limitation that would
make it impossible for a 64-bit gdbserver to debug a 32-bit
inferior (that is, multi-arch the Windows gdbserver)?
That being possible would be another reason to just merge
the files up from the start.

> 
>  - About gdbserver/configure regeneration:
> this added several lines:
> +/* Needed for new procfs interface on sparc-solaris.  */
> +#define _STRUCTURED_PROC 1
>   I did use autoconf version 2.64 as required...
> Is this normal?

Yes, it just means that someone change src/bfd/bfd.m4,
and this configure had never been regenerated
(gdbserver/acinclude.m4 pulls in bfd.m4).
You could just regenerate the file and apply that bit
alone, independently of your real gdbserver changes, so
your changes are clean.  Want to do that?

> 
>  - About the used communication library:
>   -lwsock32 was not found by the mingw, but main gdb
> doesn't seem to use it, should we move to ws2_32 for both win32 and win64?

Don't we need to make gdbserver include windows2.h instead of winsock.h too?

> 
>   I still do have a problem when I connect
> to win64 gdbserver from a multi target win32 gdb executable,
> somehow, the library list does not seem to correctly 
> read in the library addresses... Still investigating this.
> It seems related to the fact that I do not have 
> local copies of my remote DLLs.
> 

> Final question:
>   Does that patch deserve a documentation or NEWS entry?

At least the latter, definitely.

-- 
Pedro Alves

RE: [RFC] Mingw Windows 64-bit gdbserver

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : Friday, April 16, 2010 6:00 PM
> À : gdb-patches@sourceware.org
> Cc : Pierre Muller
> Objet : Re: [RFC] Mingw Windows 64-bit gdbserver
> 
> On Friday 16 April 2010 16:31:51, Pierre Muller wrote:
> >   This patch tries to implement support for
> > gdbserver on Windows 64-bit, using the mingw32
> > cross compiler to windows-64bit.
> >
> >   I am unsure if anyone else already tried this,
> > but searching in gdb-patches I didn't find anything...
> > Don't hesitate to tell me otherwise...
> >
> >   The resulting gdbserver seem usable to me,
> >
> >   I do have a few questions:
> >   - About the new file, win64-amd64-low.c
> > should I remove the copyright years and only leave 2010?
> > should I state that it is adapted from win32-i386-low.c?
> 
> How about instead merging the files, like
> linux-x86-low.c handles both 64-bit and 32-bit?  There's
> a lot of common stuff between both archs support, it
> seems.
 Yes, but ...
>  Also, is there any debug API limitation that would
> make it impossible for a 64-bit gdbserver to debug a 32-bit
> inferior (that is, multi-arch the Windows gdbserver)?
 It not impossible, but it doesn't work 
without using some new API functions:
Wow64GetThreadContext, Wow64GetThreadSelectorEntry,
and Wow64SetThreadContext

See http://msdn.microsoft.com/en-us/library/ms679303%28VS.85%29.aspx

This would also be required to be able to debug win32 
application within a windows 64-bit GDB executable.

Implementing this is probably a larger patch than this one ...

> That being possible would be another reason to just merge
> the files up from the start.

 So that argument falls!
> >
> >  - About gdbserver/configure regeneration:
> > this added several lines:
> > +/* Needed for new procfs interface on sparc-solaris.  */
> > +#define _STRUCTURED_PROC 1
> >   I did use autoconf version 2.64 as required...
> > Is this normal?
> 
> Yes, it just means that someone change src/bfd/bfd.m4,
> and this configure had never been regenerated
> (gdbserver/acinclude.m4 pulls in bfd.m4).
> You could just regenerate the file and apply that bit
> alone, independently of your real gdbserver changes, so
> your changes are clean.  Want to do that?
 Done. 
> >
> >  - About the used communication library:
> >   -lwsock32 was not found by the mingw, but main gdb
> > doesn't seem to use it, should we move to ws2_32 for both win32 and
> win64?
> 
> Don't we need to make gdbserver include windows2.h instead of winsock.h
> too?

 No, I only found #include <windows.h>
> >
> >   I still do have a problem when I connect
> > to win64 gdbserver from a multi target win32 gdb executable,
> > somehow, the library list does not seem to correctly
> > read in the library addresses... Still investigating this.
> > It seems related to the fact that I do not have
> > local copies of my remote DLLs.
> >
> 
> > Final question:
> >   Does that patch deserve a documentation or NEWS entry?
> 
> At least the latter, definitely.
  Should be easy to add.

Pierre

Re: [RFC] Mingw Windows 64-bit gdbserver

[Pedro Alves]

On Friday 16 April 2010 17:20:18, Pierre Muller wrote:
> > How about instead merging the files, like
> > linux-x86-low.c handles both 64-bit and 32-bit?  There's
> > a lot of common stuff between both archs support, it
> > seems.
>  Yes, but ...
> >  Also, is there any debug API limitation that would
> > make it impossible for a 64-bit gdbserver to debug a 32-bit
> > inferior (that is, multi-arch the Windows gdbserver)?
>  It not impossible, but it doesn't work 
> without using some new API functions:
> Wow64GetThreadContext, Wow64GetThreadSelectorEntry,
> and Wow64SetThreadContext
> 
> See http://msdn.microsoft.com/en-us/library/ms679303%28VS.85%29.aspx
> 
> This would also be required to be able to debug win32 
> application within a windows 64-bit GDB executable.
> 
> Implementing this is probably a larger patch than this one ...

I didn't mean to suggest you work on that.  Merely to
consider if once we implement that, we'll end up merging
the files anyway...

> > That being possible would be another reason to just merge
> > the files up from the start.
> 
>  So that argument falls!

Of course it doesn't.  But okay, let's keep them appart
anyway.  Easy to merge any other time.

> > >  - About the used communication library:
> > >   -lwsock32 was not found by the mingw, but main gdb
> > > doesn't seem to use it, should we move to ws2_32 for both win32 and
> > win64?
> > 
> > Don't we need to make gdbserver include windows2.h instead of winsock.h
> > too?
> 
>  No, I only found #include <windows.h>

Typo: I meant winsock2.h instead of winsock.h.

-- 
Pedro Alves

RE: [RFC] Mingw Windows 64-bit gdbserver

[Pierre Muller]

  GDb sources is still a mix:

> Typo: I meant winsock2.h instead of winsock.h.

$ grep "include.*<winso" *.h  gdbserver/*.h *.c gdbserver/*.c
gdb_select.h:#include <winsock2.h>
serial.h:#include <winsock2.h>
m32r-rom.c:#include <winsock.h>
remote-m32r-sdi.c:#include <winsock.h>
ser-base.c:#include <winsock2.h>
ser-tcp.c:#include <winsock2.h>
gdbserver/gdbreplay.c:#include <winsock.h>
gdbserver/remote-utils.c:#include <winsock.h>

should all be moved to winsock2.h?
and -lws2_32 as library?

By the way, do the m32r sources still link correctly currently?

Pierre

Re: [RFC] Mingw Windows 64-bit gdbserver

[Pedro Alves]

On Friday 16 April 2010 17:38:28, Pierre Muller wrote:
>   GDb sources is still a mix:
> 
> > Typo: I meant winsock2.h instead of winsock.h.
> 
> $ grep "include.*<winso" *.h  gdbserver/*.h *.c gdbserver/*.c
> gdb_select.h:#include <winsock2.h>
> serial.h:#include <winsock2.h>
> m32r-rom.c:#include <winsock.h>
> remote-m32r-sdi.c:#include <winsock.h>
> ser-base.c:#include <winsock2.h>
> ser-tcp.c:#include <winsock2.h>
> gdbserver/gdbreplay.c:#include <winsock.h>
> gdbserver/remote-utils.c:#include <winsock.h>
> 
> should all be moved to winsock2.h?

Probably not a real problem as we only activate
Winsock 1:

gdb/
>grep WSAStart *.c -rn
m32r-rom.c:451:      if (WSAStartup (MAKEWORD (1, 1), &wd))
ser-mingw.c:1255:  if (WSAStartup (MAKEWORD (1, 0), &wsa_data) != 0)

gdb/gdbserver/
>grep WSAStart *.c -rn
gdbreplay.c:207:          WSAStartup (MAKEWORD (1, 0), &wsad);
remote-utils.c:288:       WSAStartup (MAKEWORD (1, 0), &wsad);

Presumably winsock2.h is a superset of winsock.h and so we're
likely fine.  Wouldn't hurt to be consistent, moreso since we
include winsock2.h in some headers.

> and -lws2_32 as library?

You mean in gdbserver?  Shouldn't hurt, yeah.

> By the way, do the m32r sources still link correctly currently?

No idea.  There were recent changes to some of those
files though.

-- 
Pedro Alves

RE: [RFC] Mingw Windows 64-bit gdbserver

[Pierre Muller]

 > -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : Friday, April 16, 2010 6:00 PM
> À : gdb-patches@sourceware.org
> Cc : Pierre Muller
> Objet : Re: [RFC] Mingw Windows 64-bit gdbserver
> 
> On Friday 16 April 2010 16:31:51, Pierre Muller wrote:
> >   This patch tries to implement support for
> > gdbserver on Windows 64-bit, using the mingw32
> > cross compiler to windows-64bit.
> >
> >   I am unsure if anyone else already tried this,
> > but searching in gdb-patches I didn't find anything...
> > Don't hesitate to tell me otherwise...
> >
> >   The resulting gdbserver seem usable to me,
> >
> >   I do have a few questions:
> >   - About the new file, win64-amd64-low.c
> > should I remove the copyright years and only leave 2010?
> > should I state that it is adapted from win32-i386-low.c?
> 
> How about instead merging the files, like
> linux-x86-low.c handles both 64-bit and 32-bit?  There's
> a lot of common stuff between both archs support, it
> seems. 


  Of course, I agree with you that the two files
share a very large common portion that is identical.
  There are only two places where they really differ:
  For the call to the init_registers_XXX
and for the register mappings array.

  The main question is how should we split these parts 
off if we want to keep a common part:

  I would propose this:
  rename win32-i386-low.c to win-x86-low.c

  Create win32-i386-low.h and win64-amd64-low.h
that would have the register mappings and
a macro to define their local init_registers.

  The problem with this approach is that I 
don't know if it is OK to put
a static array (the mappings) into a header?
  If this is not regarded as a good C practice
we could use win32-i386-low.c and win64-amd64-low.c
to directly include the same things as the headers
I described above and include the C files instead.
  I was thinking that including C files directly
was  not good practice, but it is already used for the 
files generated from the XML feature files, so 
this might be a second option.

  Please just let me know which option seems
more favorable to you and I will try to 
implement it.

Pierre

Re: [RFC] Mingw Windows 64-bit gdbserver

[Pedro Alves]

On Saturday 17 April 2010 06:40:02, Pierre Muller wrote:

> > How about instead merging the files, like
> > linux-x86-low.c handles both 64-bit and 32-bit?  There's
> > a lot of common stuff between both archs support, it
> > seems. 
> 
>   Of course, I agree with you that the two files
> share a very large common portion that is identical.
>   There are only two places where they really differ:
>   For the call to the init_registers_XXX
> and for the register mappings array.
> 
>   The main question is how should we split these parts 
> off if we want to keep a common part:
> 
>   I would propose this:
>   rename win32-i386-low.c to win-x86-low.c

Lets avoid someone reading this and getting religious
against "win", and go with windows-*-low.c, just
like gdb/windows-nat.c was renamed from win32-nat.c, and
gdb has i386-windows-nat.c and amd64-windows-nat.c.

>   Create win32-i386-low.h and win64-amd64-low.h
> that would have the register mappings and
> a macro to define their local init_registers.

Yes, much better, if nothing else because that's how
gdb handles this as well.  It's always good to have the
code bases solve the same problem in the same way, so
that we can more easily keep them in sync or merge them.

Take a look at gdb/amd64-windows-nat.c, it also does something
similar to handle the common stuff, though since we have
a win32_target_ops in gdbserver, we can put the register mappings
array pointer directly in win32_target_ops instead of making it
a global.

Let's avoid macros.  Use for example the `arch_setup' callback
in the win32_target_ops vector for this, keeping the arrays
defined in the corresponding arch specific .c files.


-- 
Pedro Alves