[PATCH 00/11] C++/MinGW patches

[PATCH 00/11] C++/MinGW patches

[Pedro Alves]

I tried cross building gdb for --host=x86_64-w64-mingw32 using Fedora
20's g++ (gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)).

This fixes all issues I found which aren't already sorted in the C++
branch and/or have fixes already posted.

This is only build-tested.

Pedro Alves (11):
  [C++/mingw] ser-mingw.c casts
  [C++/mingw] Misc alloca casts
  [C++/mingw] gdb-dlfcn.c casts
  [C++/mingw] windows-nat.c casts
  [C++/mingw] gdbserver casts
  [C++/mingw] ser-tcp.c casts
  [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for
    stdint.h
  [C++/mingw] Simplify first chance exception handling
  [C++/mingw] handle_output_debug_string
  [C++/mingw] Fix windows-nat.c::xlate
  [C++/mingw] gdbserver: gdb/host signal mixup

 gdb/common/common-defs.h       |  16 +++++
 gdb/exec.c                     |   2 +-
 gdb/gdb-dlfcn.c                |   4 +-
 gdb/gdbserver/win32-i386-low.c |   5 +-
 gdb/gdbserver/win32-low.c      |  38 ++++++------
 gdb/ser-mingw.c                |  51 ++++++++--------
 gdb/ser-tcp.c                  |  19 ++++--
 gdb/symfile.c                  |   2 +-
 gdb/utils.c                    |   4 +-
 gdb/windows-nat.c              | 129 ++++++++++++++++++++++-------------------
 10 files changed, 151 insertions(+), 119 deletions(-)

-- 
1.9.3

[PATCH 02/11] [C++/mingw] Misc alloca casts

[Pedro Alves]

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* exec.c (exec_file_attach, symfile_bfd_open) [__GO32__ || _WIN32
	|| __CYGWIN__]: Add casts.
	* utils.c (gdb_filename_fnmatch): Add cast.
	* windows-nat.c (windows_create_inferior): Add cast.
---
 gdb/exec.c        | 2 +-
 gdb/symfile.c     | 2 +-
 gdb/utils.c       | 4 ++--
 gdb/windows-nat.c | 8 ++++----
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gdb/exec.c b/gdb/exec.c
index 3089bb4..2433019 100644
--- a/gdb/exec.c
+++ b/gdb/exec.c
@@ -254,7 +254,7 @@ exec_file_attach (const char *filename, int from_tty)
 #if defined(__GO32__) || defined(_WIN32) || defined(__CYGWIN__)
 	  if (scratch_chan < 0)
 	    {
-	      char *exename = alloca (strlen (filename) + 5);
+	      char *exename = (char *) alloca (strlen (filename) + 5);
 
 	      strcat (strcpy (exename, filename), ".exe");
 	      scratch_chan = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST,
diff --git a/gdb/symfile.c b/gdb/symfile.c
index 55a9f5c..58c4ff9 100644
--- a/gdb/symfile.c
+++ b/gdb/symfile.c
@@ -1738,7 +1738,7 @@ symfile_bfd_open (const char *name)
 #if defined(__GO32__) || defined(_WIN32) || defined (__CYGWIN__)
       if (desc < 0)
 	{
-	  char *exename = alloca (strlen (expanded_name) + 5);
+	  char *exename = (char *) alloca (strlen (expanded_name) + 5);
 
 	  strcat (strcpy (exename, expanded_name), ".exe");
 	  desc = openp (getenv ("PATH"),
diff --git a/gdb/utils.c b/gdb/utils.c
index bb13522..284fbbb 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -3356,14 +3356,14 @@ gdb_filename_fnmatch (const char *pattern, const char *string, int flags)
 
     /* Replace '\' by '/' in both strings.  */
 
-    pattern_slash = alloca (strlen (pattern) + 1);
+    pattern_slash = (char *) alloca (strlen (pattern) + 1);
     strcpy (pattern_slash, pattern);
     pattern = pattern_slash;
     for (; *pattern_slash != 0; pattern_slash++)
       if (IS_DIR_SEPARATOR (*pattern_slash))
 	*pattern_slash = '/';
 
-    string_slash = alloca (strlen (string) + 1);
+    string_slash = (char *) alloca (strlen (string) + 1);
     strcpy (string_slash, string);
     string = string_slash;
     for (; *string_slash != 0; string_slash++)
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index e6c396b..8dfe211 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -2209,7 +2209,7 @@ windows_create_inferior (struct target_ops *ops, char *exec_file,
      To avoid ambiguities introduced by spaces in the module name,
      we quote it.  */
   args_len = strlen (toexec) + 2 /* quotes */ + strlen (allargs) + 2;
-  args = alloca (args_len);
+  args = (char *) alloca (args_len);
   xsnprintf (args, args_len, "\"%s\" %s", toexec, allargs);
 
   flags |= DEBUG_ONLY_THIS_PROCESS;
@@ -2249,7 +2249,7 @@ windows_create_inferior (struct target_ops *ops, char *exec_file,
   /* Windows programs expect the environment block to be sorted.  */
   qsort (env, i, sizeof (char *), envvar_cmp);
 
-  w32env = alloca (envlen + 1);
+  w32env = (char *) alloca (envlen + 1);
 
   /* Copy env strings into new buffer.  */
   for (temp = w32env, i = 0; env[i] && *env[i]; i++)
@@ -2421,7 +2421,7 @@ windows_xfer_shared_libraries (struct target_ops *ops,
 				 target_gdbarch (), &obstack);
   obstack_grow_str0 (&obstack, "</library-list>\n");
 
-  buf = obstack_finish (&obstack);
+  buf = (const char *) obstack_finish (&obstack);
   len_avail = strlen (buf);
   if (offset >= len_avail)
     len= 0;
@@ -2700,7 +2700,7 @@ _initialize_check_for_gdb_ini (void)
       if (access (oldini, 0) == 0)
 	{
 	  int len = strlen (oldini);
-	  char *newini = alloca (len + 1);
+	  char *newini = (char *) alloca (len + 1);
 
 	  xsnprintf (newini, len + 1, "%.*s.gdbinit",
 		     (int) (len - (sizeof ("gdb.ini") - 1)), oldini);
-- 
1.9.3

[PATCH 01/11] [C++/mingw] ser-mingw.c casts

[Pedro Alves]

2015-11-01  Pedro Alves  <palves@redhat.com>

	* ser-mingw.c (CancelIo_ftype): New typedef.
	(CancelIo): Use CancelIo_ftype.
	(ser_windows_close, ser_windows_wait_handle)
	(ser_windows_read_prim, stop_select_thread)
	(console_select_thread, pipe_select_thread, file_select_thread)
	(ser_console_wait_handle, ser_console_done_wait_handle)
	(ser_console_close, cleanup_pipe_state, pipe_windows_close)
	(pipe_windows_write, pipe_wait_handle, pipe_done_wait_handle)
	(net_windows_socket_check_pending, net_windows_select_thread)
	(net_windows_wait_handle, net_windows_done_wait_handle)
	(net_windows_close): Add casts.
	(_initialize_ser_windows): Cast to CancelIo_ftype* instead of
	void*.
---
 gdb/ser-mingw.c | 51 ++++++++++++++++++++++++++-------------------------
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/gdb/ser-mingw.c b/gdb/ser-mingw.c
index e3a0ec9..3cab520 100644
--- a/gdb/ser-mingw.c
+++ b/gdb/ser-mingw.c
@@ -44,7 +44,8 @@ struct ser_windows_state
 /* CancelIo is not available for Windows 95 OS, so we need to use
    LoadLibrary/GetProcAddress to avoid a startup failure.  */
 #define CancelIo dyn_CancelIo
-static BOOL WINAPI (*CancelIo) (HANDLE);
+typedef BOOL WINAPI (CancelIo_ftype) (HANDLE);
+static CancelIo_ftype *CancelIo;
 
 /* Open up a real live device for serial I/O.  */
 
@@ -254,7 +255,7 @@ ser_windows_close (struct serial *scb)
      by calling close (scb->fd) below.  */
   if (CancelIo)
     CancelIo ((HANDLE) _get_osfhandle (scb->fd));
-  state = scb->state;
+  state = (struct ser_windows_state *) scb->state;
   CloseHandle (state->ov.hEvent);
   CloseHandle (state->except_event);
 
@@ -275,7 +276,7 @@ ser_windows_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
   DWORD errors;
   HANDLE h = (HANDLE) _get_osfhandle (scb->fd);
 
-  state = scb->state;
+  state = (struct ser_windows_state *) scb->state;
 
   *except = state->except_event;
   *read = state->ov.hEvent;
@@ -328,7 +329,7 @@ ser_windows_read_prim (struct serial *scb, size_t count)
   HANDLE h;
   gdb_byte *p;
 
-  state = scb->state;
+  state = (struct ser_windows_state *) scb->state;
   if (state->in_progress)
     {
       WaitForSingleObject (state->ov.hEvent, INFINITE);
@@ -532,12 +533,12 @@ stop_select_thread (struct ser_console_state *state)
 static DWORD WINAPI
 console_select_thread (void *arg)
 {
-  struct serial *scb = arg;
+  struct serial *scb = (struct serial *) arg;
   struct ser_console_state *state;
   int event_index;
   HANDLE h;
 
-  state = scb->state;
+  state = (struct ser_console_state *) scb->state;
   h = (HANDLE) _get_osfhandle (scb->fd);
 
   while (1)
@@ -635,12 +636,12 @@ fd_is_file (int fd)
 static DWORD WINAPI
 pipe_select_thread (void *arg)
 {
-  struct serial *scb = arg;
+  struct serial *scb = (struct serial *) arg;
   struct ser_console_state *state;
   int event_index;
   HANDLE h;
 
-  state = scb->state;
+  state = (struct ser_console_state *) scb->state;
   h = (HANDLE) _get_osfhandle (scb->fd);
 
   while (1)
@@ -678,12 +679,12 @@ pipe_select_thread (void *arg)
 static DWORD WINAPI
 file_select_thread (void *arg)
 {
-  struct serial *scb = arg;
+  struct serial *scb = (struct serial *) arg;
   struct ser_console_state *state;
   int event_index;
   HANDLE h;
 
-  state = scb->state;
+  state = (struct ser_console_state *) scb->state;
   h = (HANDLE) _get_osfhandle (scb->fd);
 
   while (1)
@@ -704,7 +705,7 @@ file_select_thread (void *arg)
 static void
 ser_console_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
 {
-  struct ser_console_state *state = scb->state;
+  struct ser_console_state *state = (struct ser_console_state *) scb->state;
 
   if (state == NULL)
     {
@@ -758,7 +759,7 @@ ser_console_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
 static void
 ser_console_done_wait_handle (struct serial *scb)
 {
-  struct ser_console_state *state = scb->state;
+  struct ser_console_state *state = (struct ser_console_state *) scb->state;
 
   if (state == NULL)
     return;
@@ -769,7 +770,7 @@ ser_console_done_wait_handle (struct serial *scb)
 static void
 ser_console_close (struct serial *scb)
 {
-  struct ser_console_state *state = scb->state;
+  struct ser_console_state *state = (struct ser_console_state *) scb->state;
 
   if (scb->state)
     {
@@ -854,7 +855,7 @@ free_pipe_state (struct pipe_state *ps)
 static void
 cleanup_pipe_state (void *untyped)
 {
-  struct pipe_state *ps = untyped;
+  struct pipe_state *ps = (struct pipe_state *) untyped;
 
   free_pipe_state (ps);
 }
@@ -957,7 +958,7 @@ pipe_windows_fdopen (struct serial *scb, int fd)
 static void
 pipe_windows_close (struct serial *scb)
 {
-  struct pipe_state *ps = scb->state;
+  struct pipe_state *ps = (struct pipe_state *) scb->state;
 
   /* In theory, we should try to kill the subprocess here, but the pex
      interface doesn't give us enough information to do that.  Usually
@@ -993,7 +994,7 @@ pipe_windows_read (struct serial *scb, size_t count)
 static int
 pipe_windows_write (struct serial *scb, const void *buf, size_t count)
 {
-  struct pipe_state *ps = scb->state;
+  struct pipe_state *ps = (struct pipe_state *) scb->state;
   HANDLE pipeline_in;
   DWORD written;
 
@@ -1015,7 +1016,7 @@ pipe_windows_write (struct serial *scb, const void *buf, size_t count)
 static void
 pipe_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
 {
-  struct pipe_state *ps = scb->state;
+  struct pipe_state *ps = (struct pipe_state *) scb->state;
 
   /* Have we allocated our events yet?  */
   if (ps->wait.read_event == INVALID_HANDLE_VALUE)
@@ -1036,7 +1037,7 @@ pipe_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
 static void
 pipe_done_wait_handle (struct serial *scb)
 {
-  struct pipe_state *ps = scb->state;
+  struct pipe_state *ps = (struct pipe_state *) scb->state;
 
   /* Have we allocated our events yet?  */
   if (ps->wait.read_event == INVALID_HANDLE_VALUE)
@@ -1080,7 +1081,7 @@ struct net_windows_state
 static int
 net_windows_socket_check_pending (struct serial *scb)
 {
-  struct net_windows_state *state = scb->state;
+  struct net_windows_state *state = (struct net_windows_state *) scb->state;
   unsigned long available;
 
   if (ioctlsocket (scb->fd, FIONREAD, &available) != 0)
@@ -1101,11 +1102,11 @@ net_windows_socket_check_pending (struct serial *scb)
 static DWORD WINAPI
 net_windows_select_thread (void *arg)
 {
-  struct serial *scb = arg;
+  struct serial *scb = (struct serial *) arg;
   struct net_windows_state *state;
   int event_index;
 
-  state = scb->state;
+  state = (struct net_windows_state *) scb->state;
 
   while (1)
     {
@@ -1170,7 +1171,7 @@ net_windows_select_thread (void *arg)
 static void
 net_windows_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
 {
-  struct net_windows_state *state = scb->state;
+  struct net_windows_state *state = (struct net_windows_state *) scb->state;
 
   /* Start from a clean slate.  */
   ResetEvent (state->base.read_event);
@@ -1189,7 +1190,7 @@ net_windows_wait_handle (struct serial *scb, HANDLE *read, HANDLE *except)
 static void
 net_windows_done_wait_handle (struct serial *scb)
 {
-  struct net_windows_state *state = scb->state;
+  struct net_windows_state *state = (struct net_windows_state *) scb->state;
 
   stop_select_thread (&state->base);
 }
@@ -1222,7 +1223,7 @@ net_windows_open (struct serial *scb, const char *name)
 static void
 net_windows_close (struct serial *scb)
 {
-  struct net_windows_state *state = scb->state;
+  struct net_windows_state *state = (struct net_windows_state *) scb->state;
 
   destroy_select_thread (&state->base);
   CloseHandle (state->sock_event);
@@ -1370,7 +1371,7 @@ _initialize_ser_windows (void)
   hm = LoadLibrary ("kernel32.dll");
   if (hm)
     {
-      CancelIo = (void *) GetProcAddress (hm, "CancelIo");
+      CancelIo = (CancelIo_ftype *) GetProcAddress (hm, "CancelIo");
       FreeLibrary (hm);
     }
   else
-- 
1.9.3

[PATCH 06/11] [C++/mingw] ser-tcp.c casts

[Pedro Alves]

Fixes a few errors like these:

../../src/gdb/ser-tcp.c: In function 'int net_open(serial*, const char*)':
../../src/gdb/ser-tcp.c:286:73: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
     res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
                                                                         ^

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* ser-tcp.c (net_open) [USE_WIN32API]: Cast getsockopt argument to
	char * instead of void *.
	(net_read_prim): Cast recv argument to
	char * instead of void *.
	(net_write_prim): Cast send argument to char * instead of void *.
---
 gdb/ser-tcp.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/gdb/ser-tcp.c b/gdb/ser-tcp.c
index ce40b61..507e0a1 100644
--- a/gdb/ser-tcp.c
+++ b/gdb/ser-tcp.c
@@ -280,10 +280,12 @@ net_open (struct serial *scb, const char *name)
 
     len = sizeof (err);
     /* On Windows, the fourth parameter to getsockopt is a "char *";
-       on UNIX systems it is generally "void *".  The cast to "void *"
-       is OK everywhere, since in C "void *" can be implicitly
-       converted to any pointer type.  */
+       on UNIX systems it is generally "void *".  */
+#ifdef USE_WIN32API
+    res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (char *) &err, &len);
+#else
     res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
+#endif
     if (res < 0 || err)
       {
 	/* Maybe the target still isn't ready to accept the connection.  */
@@ -339,16 +341,21 @@ net_close (struct serial *scb)
 int
 net_read_prim (struct serial *scb, size_t count)
 {
-  /* Need to cast to silence -Wpointer-sign on MinGW, as Winsock's
-     'recv' takes 'char *' as second argument, while 'scb->buf' is
-     'unsigned char *'.  */
+#ifdef USE_WIN32API
+  return recv (scb->fd, (char *) scb->buf, count, 0);
+#else
   return recv (scb->fd, (void *) scb->buf, count, 0);
+#endif
 }
 
 int
 net_write_prim (struct serial *scb, const void *buf, size_t count)
 {
+#ifdef USE_WIN32API
+  return send (scb->fd, (const char *) buf, count, 0);
+#else
   return send (scb->fd, buf, count, 0);
+#endif
 }
 
 int
-- 
1.9.3

Re: [PATCH 06/11] [C++/mingw] ser-tcp.c casts

[Simon Marchi]

On 15-11-02 02:36 PM, Pedro Alves wrote:
> Fixes a few errors like these:
> 
> ../../src/gdb/ser-tcp.c: In function 'int net_open(serial*, const char*)':
> ../../src/gdb/ser-tcp.c:286:73: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
>      res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
>                                                                          ^
> 
> gdb/ChangeLog:
> 2015-11-01  Pedro Alves  <palves@redhat.com>
> 
> 	* ser-tcp.c (net_open) [USE_WIN32API]: Cast getsockopt argument to
> 	char * instead of void *.
> 	(net_read_prim): Cast recv argument to
> 	char * instead of void *.
> 	(net_write_prim): Cast send argument to char * instead of void *.
> ---
>  gdb/ser-tcp.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/gdb/ser-tcp.c b/gdb/ser-tcp.c
> index ce40b61..507e0a1 100644
> --- a/gdb/ser-tcp.c
> +++ b/gdb/ser-tcp.c
> @@ -280,10 +280,12 @@ net_open (struct serial *scb, const char *name)
>  
>      len = sizeof (err);
>      /* On Windows, the fourth parameter to getsockopt is a "char *";
> -       on UNIX systems it is generally "void *".  The cast to "void *"
> -       is OK everywhere, since in C "void *" can be implicitly
> -       converted to any pointer type.  */
> +       on UNIX systems it is generally "void *".  */
> +#ifdef USE_WIN32API
> +    res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (char *) &err, &len);
> +#else
>      res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
> +#endif

You could have done exactly the opposite of the old comment, that is cast to
(char *).  It shouldn't generate any warning in either case.  But I think that
your way is fine too.

Re: [PATCH 06/11] [C++/mingw] ser-tcp.c casts

[Pedro Alves]

On 11/02/2015 08:40 PM, Simon Marchi wrote:
> On 15-11-02 02:36 PM, Pedro Alves wrote:
>> Fixes a few errors like these:
>>
>> ../../src/gdb/ser-tcp.c: In function 'int net_open(serial*, const char*)':
>> ../../src/gdb/ser-tcp.c:286:73: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
>>      res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
>>                                                                          ^
>>
>> gdb/ChangeLog:
>> 2015-11-01  Pedro Alves  <palves@redhat.com>
>>
>> 	* ser-tcp.c (net_open) [USE_WIN32API]: Cast getsockopt argument to
>> 	char * instead of void *.
>> 	(net_read_prim): Cast recv argument to
>> 	char * instead of void *.
>> 	(net_write_prim): Cast send argument to char * instead of void *.
>> ---
>>  gdb/ser-tcp.c | 19 +++++++++++++------
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/gdb/ser-tcp.c b/gdb/ser-tcp.c
>> index ce40b61..507e0a1 100644
>> --- a/gdb/ser-tcp.c
>> +++ b/gdb/ser-tcp.c
>> @@ -280,10 +280,12 @@ net_open (struct serial *scb, const char *name)
>>  
>>      len = sizeof (err);
>>      /* On Windows, the fourth parameter to getsockopt is a "char *";
>> -       on UNIX systems it is generally "void *".  The cast to "void *"
>> -       is OK everywhere, since in C "void *" can be implicitly
>> -       converted to any pointer type.  */
>> +       on UNIX systems it is generally "void *".  */
>> +#ifdef USE_WIN32API
>> +    res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (char *) &err, &len);
>> +#else
>>      res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
>> +#endif
> 
> You could have done exactly the opposite of the old comment, that is cast to
> (char *).  It shouldn't generate any warning in either case.  But I think that
> your way is fine too.

Oh, good point.  I always forget that implicit cast to void* works.

I'll update the patch.

Thanks,
Pedro Alves

Re: [PATCH 06/11] [C++/mingw] ser-tcp.c casts

[Pedro Alves]

On 11/02/2015 08:55 PM, Pedro Alves wrote:
> On 11/02/2015 08:40 PM, Simon Marchi wrote:

>> You could have done exactly the opposite of the old comment, that is cast to
>> (char *).  It shouldn't generate any warning in either case.  But I think that
>> your way is fine too.
> 
> Oh, good point.  I always forget that implicit cast to void* works.
> 
> I'll update the patch.

Here it is.  Build tested on GNU/Linux and mingw.

---
From 574dbd59c93e29f494bad7688cb04b1672d3980a Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Mon, 2 Nov 2015 20:56:15 +0000
Subject: [PATCH] [C++/mingw] ser-tcp.c casts

Fixes a few errors like these:

../../src/gdb/ser-tcp.c: In function 'int net_open(serial*, const char*)':
../../src/gdb/ser-tcp.c:286:73: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
     res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
                                                                         ^

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* ser-tcp.c (net_open) : Cast getsockopt argument to char *
	instead of void *.  Update comment.
	(net_read_prim): Cast recv argument to char * instead of void *.
	(net_write_prim): Cast send argument to char *.  Add comment.
---
 gdb/ser-tcp.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/gdb/ser-tcp.c b/gdb/ser-tcp.c
index ce40b61..36196f3 100644
--- a/gdb/ser-tcp.c
+++ b/gdb/ser-tcp.c
@@ -280,10 +280,10 @@ net_open (struct serial *scb, const char *name)
 
     len = sizeof (err);
     /* On Windows, the fourth parameter to getsockopt is a "char *";
-       on UNIX systems it is generally "void *".  The cast to "void *"
-       is OK everywhere, since in C "void *" can be implicitly
-       converted to any pointer type.  */
-    res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (void *) &err, &len);
+       on UNIX systems it is generally "void *".  The cast to "char *"
+       is OK everywhere, since in C++ any data pointer type can be
+       implicitly converted to "void *".  */
+    res = getsockopt (scb->fd, SOL_SOCKET, SO_ERROR, (char *) &err, &len);
     if (res < 0 || err)
       {
 	/* Maybe the target still isn't ready to accept the connection.  */
@@ -342,13 +342,17 @@ net_read_prim (struct serial *scb, size_t count)
   /* Need to cast to silence -Wpointer-sign on MinGW, as Winsock's
      'recv' takes 'char *' as second argument, while 'scb->buf' is
      'unsigned char *'.  */
-  return recv (scb->fd, (void *) scb->buf, count, 0);
+  return recv (scb->fd, (char *) scb->buf, count, 0);
 }
 
 int
 net_write_prim (struct serial *scb, const void *buf, size_t count)
 {
-  return send (scb->fd, buf, count, 0);
+  /* On Windows, the second parameter to send is a "const char *"; on
+     UNIX systems it is generally "const void *".  The cast to "const
+     char *" is OK everywhere, since in C++ any data pointer type can
+     be implicitly converted to "const void *".  */
+  return send (scb->fd, (const char *) buf, count, 0);
 }
 
 int
-- 
1.9.3

[PATCH 04/11] [C++/mingw] windows-nat.c casts

[Pedro Alves]

Fixes a set of errors like:

../../src/gdb/windows-nat.c: In function 'void _initialize_loadable()':
../../src/gdb/windows-nat.c:2778:30: error: invalid conversion from 'void*' to 'BOOL (*)(DWORD) {aka int (*)(long unsigned int)}' [-fpermissive]
       DebugActiveProcessStop = (void *)
                              ^

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* windows-nat.c (AdjustTokenPrivileges_ftype)
	(DebugActiveProcessStop_ftype, DebugBreakProcess_ftype)
	(DebugSetProcessKillOnExit_ftype, EnumProcessModules_ftype)
	(GetCurrentConsoleFont_ftype, GetModuleInformation_ftype)
	(LookupPrivilegeValueA_ftype, OpenProcessToken_ftype)
	(GetConsoleFontSize_ftype): New typedefs.
	(AdjustTokenPrivileges, DebugActiveProcessStop)
	(DebugBreakProcess, DebugSetProcessKillOnExit, EnumProcessModules)
	(GetConsoleFontSize, GetCurrentConsoleFont, GetModuleInformation)
	(LookupPrivilegeValueA, OpenProcessToken, GetConsoleFontSize):
	Adjust.
	(GetModuleFileNameEx_ftype): New typedef.
	(GetModuleFileNameEx): Use it.
	(_initialize_loadable): Define GPA macro and use it.
---
 gdb/windows-nat.c | 95 +++++++++++++++++++++++++++++++++----------------------
 1 file changed, 57 insertions(+), 38 deletions(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 8dfe211..2e12493 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -77,20 +77,41 @@
 #define GetConsoleFontSize		dyn_GetConsoleFontSize
 #define GetCurrentConsoleFont		dyn_GetCurrentConsoleFont
 
-static BOOL WINAPI (*AdjustTokenPrivileges)(HANDLE, BOOL, PTOKEN_PRIVILEGES,
-					    DWORD, PTOKEN_PRIVILEGES, PDWORD);
-static BOOL WINAPI (*DebugActiveProcessStop) (DWORD);
-static BOOL WINAPI (*DebugBreakProcess) (HANDLE);
-static BOOL WINAPI (*DebugSetProcessKillOnExit) (BOOL);
-static BOOL WINAPI (*EnumProcessModules) (HANDLE, HMODULE *, DWORD,
-					  LPDWORD);
-static BOOL WINAPI (*GetModuleInformation) (HANDLE, HMODULE, LPMODULEINFO,
-					    DWORD);
-static BOOL WINAPI (*LookupPrivilegeValueA)(LPCSTR, LPCSTR, PLUID);
-static BOOL WINAPI (*OpenProcessToken)(HANDLE, DWORD, PHANDLE);
-static BOOL WINAPI (*GetCurrentConsoleFont) (HANDLE, BOOL,
-					     CONSOLE_FONT_INFO *);
-static COORD WINAPI (*GetConsoleFontSize) (HANDLE, DWORD);
+typedef BOOL WINAPI (AdjustTokenPrivileges_ftype) (HANDLE, BOOL,
+						   PTOKEN_PRIVILEGES,
+						   DWORD, PTOKEN_PRIVILEGES,
+						   PDWORD);
+static AdjustTokenPrivileges_ftype *AdjustTokenPrivileges;
+
+typedef BOOL WINAPI (DebugActiveProcessStop_ftype) (DWORD);
+static DebugActiveProcessStop_ftype *DebugActiveProcessStop;
+
+typedef BOOL WINAPI (DebugBreakProcess_ftype) (HANDLE);
+static DebugBreakProcess_ftype *DebugBreakProcess;
+
+typedef BOOL WINAPI (DebugSetProcessKillOnExit_ftype) (BOOL);
+static DebugSetProcessKillOnExit_ftype *DebugSetProcessKillOnExit;
+
+typedef BOOL WINAPI (EnumProcessModules_ftype) (HANDLE, HMODULE *, DWORD,
+						LPDWORD);
+static EnumProcessModules_ftype *EnumProcessModules;
+
+typedef BOOL WINAPI (GetModuleInformation_ftype) (HANDLE, HMODULE,
+						  LPMODULEINFO, DWORD);
+static GetModuleInformation_ftype *GetModuleInformation;
+
+typedef BOOL WINAPI (LookupPrivilegeValueA_ftype) (LPCSTR, LPCSTR, PLUID);
+static LookupPrivilegeValueA_ftype *LookupPrivilegeValueA;
+
+typedef BOOL WINAPI (OpenProcessToken_ftype) (HANDLE, DWORD, PHANDLE);
+static OpenProcessToken_ftype *OpenProcessToken;
+
+typedef BOOL WINAPI (GetCurrentConsoleFont_ftype) (HANDLE, BOOL,
+						   CONSOLE_FONT_INFO *);
+static GetCurrentConsoleFont_ftype *GetCurrentConsoleFont;
+
+typedef COORD WINAPI (GetConsoleFontSize_ftype) (HANDLE, DWORD);
+static GetConsoleFontSize_ftype *GetConsoleFontSize;
 
 #undef STARTUPINFO
 #undef CreateProcess
@@ -98,7 +119,8 @@ static COORD WINAPI (*GetConsoleFontSize) (HANDLE, DWORD);
 
 #ifndef __CYGWIN__
 # define __PMAX	(MAX_PATH + 1)
-  static DWORD WINAPI (*GetModuleFileNameEx) (HANDLE, HMODULE, LPSTR, DWORD);
+  typedef DWORD WINAPI (GetModuleFileNameEx_ftype) (HANDLE, HMODULE, LPSTR, DWORD);
+  static GetModuleFileNameEx_ftype *GetModuleFileNameEx;
 # define STARTUPINFO STARTUPINFOA
 # define CreateProcess CreateProcessA
 # define GetModuleFileNameEx_name "GetModuleFileNameExA"
@@ -110,8 +132,9 @@ static COORD WINAPI (*GetConsoleFontSize) (HANDLE, DWORD);
   static CORE_ADDR cygwin_load_end;
 #   define __USEWIDE
     typedef wchar_t cygwin_buf_t;
-    static DWORD WINAPI (*GetModuleFileNameEx) (HANDLE, HMODULE,
-						LPWSTR, DWORD);
+    typedef DWORD WINAPI (GetModuleFileNameEx_ftype) (HANDLE, HMODULE,
+						      LPWSTR, DWORD);
+    static GetModuleFileNameEx_ftype *GetModuleFileNameEx;
 #   define STARTUPINFO STARTUPINFOW
 #   define CreateProcess CreateProcessW
 #   define GetModuleFileNameEx_name "GetModuleFileNameExW"
@@ -2784,19 +2807,18 @@ _initialize_loadable (void)
 {
   HMODULE hm = NULL;
 
+#define GPA(m, func)					\
+  func = (func ## _ftype *) GetProcAddress (m, #func)
+
   hm = LoadLibrary ("kernel32.dll");
   if (hm)
     {
-      DebugActiveProcessStop = (void *)
-	GetProcAddress (hm, "DebugActiveProcessStop");
-      DebugBreakProcess = (void *)
-	GetProcAddress (hm, "DebugBreakProcess");
-      DebugSetProcessKillOnExit = (void *)
-	GetProcAddress (hm, "DebugSetProcessKillOnExit");
-      GetConsoleFontSize = (void *) 
-	GetProcAddress (hm, "GetConsoleFontSize");
-      GetCurrentConsoleFont = (void *) 
-	GetProcAddress (hm, "GetCurrentConsoleFont");
+      GPA (hm, DebugActiveProcessStop);
+      GPA (hm, DebugBreakProcess);
+      GPA (hm, DebugSetProcessKillOnExit);
+      GPA (hm, GetConsoleFontSize);
+      GPA (hm, DebugActiveProcessStop);
+      GPA (hm, GetCurrentConsoleFont);
     }
 
   /* Set variables to dummy versions of these processes if the function
@@ -2818,12 +2840,9 @@ _initialize_loadable (void)
   hm = LoadLibrary ("psapi.dll");
   if (hm)
     {
-      EnumProcessModules = (void *)
-	GetProcAddress (hm, "EnumProcessModules");
-      GetModuleInformation = (void *)
-	GetProcAddress (hm, "GetModuleInformation");
-      GetModuleFileNameEx = (void *)
-	GetProcAddress (hm, GetModuleFileNameEx_name);
+      GPA (hm, EnumProcessModules);
+      GPA (hm, GetModuleInformation);
+      GPA (hm, GetModuleFileNameEx);
     }
 
   if (!EnumProcessModules || !GetModuleInformation || !GetModuleFileNameEx)
@@ -2843,15 +2862,15 @@ Use \"file\" or \"dll\" command to load executable/libraries directly."));
   hm = LoadLibrary ("advapi32.dll");
   if (hm)
     {
-      OpenProcessToken = (void *) GetProcAddress (hm, "OpenProcessToken");
-      LookupPrivilegeValueA = (void *)
-	GetProcAddress (hm, "LookupPrivilegeValueA");
-      AdjustTokenPrivileges = (void *)
-	GetProcAddress (hm, "AdjustTokenPrivileges");
+      GPA (hm, OpenProcessToken);
+      GPA (hm, LookupPrivilegeValueA);
+      GPA (hm, AdjustTokenPrivileges);
       /* Only need to set one of these since if OpenProcessToken fails nothing
 	 else is needed.  */
       if (!OpenProcessToken || !LookupPrivilegeValueA
 	  || !AdjustTokenPrivileges)
 	OpenProcessToken = bad_OpenProcessToken;
     }
+
+#undef GPA
 }
-- 
1.9.3

[PATCH 11/11] [C++/mingw] gdbserver: gdb/host signal mixup

[Pedro Alves]

Building in C++ caught a buglet here:

../../../src/gdb/gdbserver/win32-low.c: In function 'void win32_resume(thread_resume*, size_t)':
../../../src/gdb/gdbserver/win32-low.c:929:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
       sig = resume_info[0].sig;
           ^
../../../src/gdb/gdbserver/win32-low.c:934:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
       sig = 0;
           ^

Signals in the "struct thread_resume" structure are host signals, not
gdb signals.  The current code happens to work because the only
signals that the Windows port supports have the same number as the gdb
equivalent (see handle_exception for the win32 exception -> gdb signal
mapping).

gdb/gdbserver/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* win32-low.c (win32_resume): Use gdb_signal_from_host,
	GDB_SIGNAL_0 and gdb_signal_to_string.
---
 gdb/gdbserver/win32-low.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/gdb/gdbserver/win32-low.c b/gdb/gdbserver/win32-low.c
index b1a2e56..b1de139 100644
--- a/gdb/gdbserver/win32-low.c
+++ b/gdb/gdbserver/win32-low.c
@@ -926,12 +926,12 @@ win32_resume (struct thread_resume *resume_info, size_t n)
 
   if (!ptid_equal (resume_info[0].thread, minus_one_ptid))
     {
-      sig = resume_info[0].sig;
+      sig = gdb_signal_from_host (resume_info[0].sig);
       step = resume_info[0].kind == resume_step;
     }
   else
     {
-      sig = 0;
+      sig = GDB_SIGNAL_0;
       step = 0;
     }
 
@@ -939,12 +939,14 @@ win32_resume (struct thread_resume *resume_info, size_t n)
     {
       if (current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT)
 	{
-	  OUTMSG (("Cannot continue with signal %d here.\n", sig));
+	  OUTMSG (("Cannot continue with signal %s here.\n",
+		   gdb_signal_to_string (sig)));
 	}
       else if (sig == last_sig)
 	continue_status = DBG_EXCEPTION_NOT_HANDLED;
       else
-	OUTMSG (("Can only continue with recieved signal %d.\n", last_sig));
+	OUTMSG (("Can only continue with received signal %s.\n",
+		 gdb_signal_to_string (last_sig)));
     }
 
   last_sig = GDB_SIGNAL_0;
-- 
1.9.3

[PATCH 10/11] [C++/mingw] Fix windows-nat.c::xlate

[Pedro Alves]

Fixes:

../../src/gdb/windows-nat.c:287:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
   {-1, -1}};
           ^

The signal number here doesn't really matter.

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* windows-nat.c (xslate): Use GDB_SIGNAL_UNKNOWN instead of -1 as
	signal number for terminator.
---
 gdb/windows-nat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index cfbd74a..a7132d6 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -284,7 +284,7 @@ static const struct xlate_exception
   {DBG_CONTROL_C, GDB_SIGNAL_INT},
   {EXCEPTION_SINGLE_STEP, GDB_SIGNAL_TRAP},
   {STATUS_FLOAT_DIVIDE_BY_ZERO, GDB_SIGNAL_FPE},
-  {-1, -1}};
+  {-1, GDB_SIGNAL_UNKNOWN}};
 
 /* Set the MAPPINGS static global to OFFSETS.
    See the description of MAPPINGS for more details.  */
-- 
1.9.3

[PATCH 03/11] [C++/mingw] gdb-dlfcn.c casts

[Pedro Alves]

Fixes:

../../src/gdb/gdb-dlfcn.c: In function 'void* gdb_dlsym(void*, const char*)':
../../src/gdb/gdb-dlfcn.c:105:49: error: invalid conversion from 'void*' to 'HMODULE {aka HINSTANCE__*}' [-fpermissive]
   return (void *) GetProcAddress (handle, symbol);
                                                 ^

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* gdb-dlfcn.c (gdb_dlsym, gdb_dlclose) [__MINGW32__]: Add casts to
	HMODULE.
---
 gdb/gdb-dlfcn.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gdb/gdb-dlfcn.c b/gdb/gdb-dlfcn.c
index fb6dc5f..fbd3a49 100644
--- a/gdb/gdb-dlfcn.c
+++ b/gdb/gdb-dlfcn.c
@@ -102,7 +102,7 @@ gdb_dlsym (void *handle, const char *symbol)
 #ifdef HAVE_DLFCN_H
   return dlsym (handle, symbol);
 #elif __MINGW32__
-  return (void *) GetProcAddress (handle, symbol);
+  return (void *) GetProcAddress ((HMODULE) handle, symbol);
 #endif
 }
 
@@ -112,7 +112,7 @@ gdb_dlclose (void *handle)
 #ifdef HAVE_DLFCN_H
   return dlclose (handle);
 #elif __MINGW32__
-  return !((int) FreeLibrary (handle));
+  return !((int) FreeLibrary ((HMODULE) handle));
 #endif
 }
 
-- 
1.9.3

[PATCH 09/11] [C++/mingw] handle_output_debug_string

[Pedro Alves]

Fixes:

 ../../../src/gdb/gdbserver/win32-low.c: In function 'int win32_kill(int)':
 ../../../src/gdb/gdbserver/win32-low.c:823:46: error: invalid conversion from 'int' to 'target_waitkind' [-fpermissive]
     struct target_waitstatus our_status = { 0 };
					       ^

handle_output_debug_string doesn't use the parameter for anything
(it's an output parameter in the gdb version), so just remove it.

gdb/gdbserver/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* win32-low.c (handle_output_debug_string): Remove parameter.
	(win32_kill): Remove our_status local and adjust call to
	handle_output_debug_string.
	(get_child_debug_event): Adjust call to
	handle_output_debug_string.
---
 gdb/gdbserver/win32-low.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/gdb/gdbserver/win32-low.c b/gdb/gdbserver/win32-low.c
index 2b40ca3..b1a2e56 100644
--- a/gdb/gdbserver/win32-low.c
+++ b/gdb/gdbserver/win32-low.c
@@ -747,7 +747,7 @@ win32_attach (unsigned long pid)
 
 /* Handle OUTPUT_DEBUG_STRING_EVENT from child process.  */
 static void
-handle_output_debug_string (struct target_waitstatus *ourstatus)
+handle_output_debug_string (void)
 {
 #define READ_BUFFER_LEN 1024
   CORE_ADDR addr;
@@ -819,10 +819,7 @@ win32_kill (int pid)
       if (current_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT)
 	break;
       else if (current_event.dwDebugEventCode == OUTPUT_DEBUG_STRING_EVENT)
-	{
-	  struct target_waitstatus our_status = { 0 };
-	  handle_output_debug_string (&our_status);
-	}
+	handle_output_debug_string ();
     }
 
   win32_clear_inferiors ();
@@ -1572,7 +1569,7 @@ get_child_debug_event (struct target_waitstatus *ourstatus)
 		"for pid=%u tid=%x\n",
 		(unsigned) current_event.dwProcessId,
 		(unsigned) current_event.dwThreadId));
-      handle_output_debug_string (ourstatus);
+      handle_output_debug_string ();
       break;
 
     default:
-- 
1.9.3

[PATCH 05/11] [C++/mingw] gdbserver casts

[Pedro Alves]

A set of obviously-needed C++ casts.

gdb/gdbserver/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* win32-i386-low.c (update_debug_registers_callback)
	(win32_get_current_dr): Add cast.
	* win32-low.c (thread_rec, delete_thread_info)
	(continue_one_thread): Add casts.
	(strwinerror): Cast FormatMessage argument to LPTSTR instead of
	LPVOID.
	(win32_create_inferior, suspend_one_thread): Add casts.
---
 gdb/gdbserver/win32-i386-low.c |  5 +++--
 gdb/gdbserver/win32-low.c      | 19 ++++++++++---------
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/gdb/gdbserver/win32-i386-low.c b/gdb/gdbserver/win32-i386-low.c
index 7c22f05..686521f 100644
--- a/gdb/gdbserver/win32-i386-low.c
+++ b/gdb/gdbserver/win32-i386-low.c
@@ -45,7 +45,7 @@ update_debug_registers_callback (struct inferior_list_entry *entry,
 				 void *pid_p)
 {
   struct thread_info *thr = (struct thread_info *) entry;
-  win32_thread_info *th = inferior_target_data (thr);
+  win32_thread_info *th = (win32_thread_info *) inferior_target_data (thr);
   int pid = *(int *) pid_p;
 
   /* Only update the threads of this process.  */
@@ -89,7 +89,8 @@ x86_dr_low_set_control (unsigned long control)
 static DWORD64
 win32_get_current_dr (int dr)
 {
-  win32_thread_info *th = inferior_target_data (current_thread);
+  win32_thread_info *th
+    = (win32_thread_info *) inferior_target_data (current_thread);
 
   win32_require_context (th);
 
diff --git a/gdb/gdbserver/win32-low.c b/gdb/gdbserver/win32-low.c
index 6e33509..2b40ca3 100644
--- a/gdb/gdbserver/win32-low.c
+++ b/gdb/gdbserver/win32-low.c
@@ -198,7 +198,7 @@ thread_rec (ptid_t ptid, int get_context)
   if (thread == NULL)
     return NULL;
 
-  th = inferior_target_data (thread);
+  th = (win32_thread_info *) inferior_target_data (thread);
   if (get_context)
     win32_require_context (th);
   return th;
@@ -229,11 +229,12 @@ child_add_thread (DWORD pid, DWORD tid, HANDLE h, void *tlb)
 
 /* Delete a thread from the list of threads.  */
 static void
-delete_thread_info (struct inferior_list_entry *thread)
+delete_thread_info (struct inferior_list_entry *entry)
 {
-  win32_thread_info *th = inferior_target_data ((struct thread_info *) thread);
+  struct thread_info *thread = (struct thread_info *) entry;
+  win32_thread_info *th = (win32_thread_info *) inferior_target_data (thread);
 
-  remove_thread ((struct thread_info *) thread);
+  remove_thread (thread);
   CloseHandle (th->h);
   free (th);
 }
@@ -432,7 +433,7 @@ continue_one_thread (struct inferior_list_entry *this_thread, void *id_ptr)
 {
   struct thread_info *thread = (struct thread_info *) this_thread;
   int thread_id = * (int *) id_ptr;
-  win32_thread_info *th = inferior_target_data (thread);
+  win32_thread_info *th = (win32_thread_info *) inferior_target_data (thread);
 
   if (thread_id == -1 || thread_id == th->tid)
     {
@@ -523,7 +524,7 @@ strwinerror (DWORD error)
 			       NULL,
 			       error,
 			       0, /* Default language */
-			       (LPVOID)&msgbuf,
+			       (LPTSTR) &msgbuf,
 			       0,
 			       NULL);
   if (chars != 0)
@@ -654,7 +655,7 @@ win32_create_inferior (char *program, char **program_args)
   argslen = 1;
   for (argc = 1; program_args[argc]; argc++)
     argslen += strlen (program_args[argc]) + 1;
-  args = alloca (argslen);
+  args = (char *) alloca (argslen);
   args[0] = '\0';
   for (argc = 1; program_args[argc]; argc++)
     {
@@ -673,7 +674,7 @@ win32_create_inferior (char *program, char **program_args)
   err = GetLastError ();
   if (!ret && err == ERROR_FILE_NOT_FOUND)
     {
-      char *exename = alloca (strlen (program) + 5);
+      char *exename = (char *) alloca (strlen (program) + 5);
       strcat (strcpy (exename, program), ".exe");
       ret = create_process (exename, args, flags, &pi);
       err = GetLastError ();
@@ -1344,7 +1345,7 @@ static void
 suspend_one_thread (struct inferior_list_entry *entry)
 {
   struct thread_info *thread = (struct thread_info *) entry;
-  win32_thread_info *th = inferior_target_data (thread);
+  win32_thread_info *th = (win32_thread_info *) inferior_target_data (thread);
 
   if (!th->suspended)
     {
-- 
1.9.3

[PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

[Pedro Alves]

Cross building for --host=x86_64-w64-mingw32 using Fedora 20's g++
(gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)), stumbles on
many instances of:

 In file included from ../../src/gdb/../include/splay-tree.h:43:0,
                  from ../../src/gdb/dcache.c:26:
 build-gnulib/import/inttypes.h:61:3: error: #error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
  # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
    ^
 make: *** [dcache.o] Error 1

That's:

 #if !(INT_MIN == INT32_MIN && INT_MAX == INT32_MAX)
 # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
 #endif

The issue is that on some hosts that predate C++11, when using C++ one
must define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS to make visible
the definitions of INTMAX_C / INTMAX_MAX etc.

This was a C99 requirement that later C++11 -- the first to define
stdint.h -- removed, and then C11 removed it as well.

https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
says that gnulib's stdint.h fixes this, but because we run gnulib's
configure tests with a C compiler, gnulib determines that mingw's
stdint.h is C99-compliant, and doesn't actually replace it.  Actually,
even though configuring gnulib with a C++ compiler does result in
gnulib replacing stdint.h, the resulting replacement is broken for
mingw, because it defines uintptr_t incorrectly.  I sent a gnulib
patch upstream to fix that, here:

  https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html

but then even with that, gnulib still stumbles on other
configured-with-C++-compiler problems.

So for now, until gnulib + C++ is fixed upstream and then gdb's copy
is updated, which may take a while, I think it's best to keep
configuring gnulib in C, and define
__STDC_LIMIT_MACROS/__STDC_CONSTANT_MACROS ourselves, just like C99
intended.

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* common/common-defs.h (__STDC_CONSTANT_MACROS)
	(__STDC_LIMIT_MACROS): Define before including stdint.h.
---
 gdb/common/common-defs.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
index 2be0d7d..59b1887 100644
--- a/gdb/common/common-defs.h
+++ b/gdb/common/common-defs.h
@@ -31,7 +31,23 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <stddef.h>
+
+/* From:
+    https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
+
+   "On some hosts that predate C++11, when using C++ one must define
+   __STDC_CONSTANT_MACROS to make visible the definitions of constant
+   macros such as INTMAX_C, and one must define __STDC_LIMIT_MACROS to
+   make visible the definitions of limit macros such as INTMAX_MAX."
+
+   gnulib doesn't fix this for us correctly yet.  See:
+     https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
+
+   Meanwhile, explicitly define these ourselves, as C99 intended.  */
+#define __STDC_CONSTANT_MACROS
+#define __STDC_LIMIT_MACROS
 #include <stdint.h>
+
 #include <string.h>
 #include <errno.h>
 #include <alloca.h>
-- 
1.9.3

Re: [PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

[Simon Marchi]

On 15-11-02 02:36 PM, Pedro Alves wrote:
> Cross building for --host=x86_64-w64-mingw32 using Fedora 20's g++
> (gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)), stumbles on
> many instances of:
> 
>  In file included from ../../src/gdb/../include/splay-tree.h:43:0,
>                   from ../../src/gdb/dcache.c:26:
>  build-gnulib/import/inttypes.h:61:3: error: #error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
>   # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
>     ^
>  make: *** [dcache.o] Error 1
> 
> That's:
> 
>  #if !(INT_MIN == INT32_MIN && INT_MAX == INT32_MAX)
>  # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
>  #endif
> 
> The issue is that on some hosts that predate C++11, when using C++ one
> must define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS to make visible
> the definitions of INTMAX_C / INTMAX_MAX etc.
> 
> This was a C99 requirement that later C++11 -- the first to define
> stdint.h -- removed, and then C11 removed it as well.
> 
> https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
> says that gnulib's stdint.h fixes this, but because we run gnulib's
> configure tests with a C compiler, gnulib determines that mingw's
> stdint.h is C99-compliant, and doesn't actually replace it.  Actually,
> even though configuring gnulib with a C++ compiler does result in
> gnulib replacing stdint.h, the resulting replacement is broken for
> mingw, because it defines uintptr_t incorrectly.  I sent a gnulib
> patch upstream to fix that, here:
> 
>   https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
> 
> but then even with that, gnulib still stumbles on other
> configured-with-C++-compiler problems.
> 
> So for now, until gnulib + C++ is fixed upstream and then gdb's copy
> is updated, which may take a while, I think it's best to keep
> configuring gnulib in C, and define
> __STDC_LIMIT_MACROS/__STDC_CONSTANT_MACROS ourselves, just like C99
> intended.
> 
> gdb/ChangeLog:
> 2015-11-01  Pedro Alves  <palves@redhat.com>
> 
> 	* common/common-defs.h (__STDC_CONSTANT_MACROS)
> 	(__STDC_LIMIT_MACROS): Define before including stdint.h.
> ---
>  gdb/common/common-defs.h | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
> index 2be0d7d..59b1887 100644
> --- a/gdb/common/common-defs.h
> +++ b/gdb/common/common-defs.h
> @@ -31,7 +31,23 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <stddef.h>
> +
> +/* From:
> +    https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
> +
> +   "On some hosts that predate C++11, when using C++ one must define
> +   __STDC_CONSTANT_MACROS to make visible the definitions of constant
> +   macros such as INTMAX_C, and one must define __STDC_LIMIT_MACROS to
> +   make visible the definitions of limit macros such as INTMAX_MAX."
> +
> +   gnulib doesn't fix this for us correctly yet.  See:
> +     https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
> +
> +   Meanwhile, explicitly define these ourselves, as C99 intended.  */
> +#define __STDC_CONSTANT_MACROS
> +#define __STDC_LIMIT_MACROS
>  #include <stdint.h>
> +
>  #include <string.h>
>  #include <errno.h>
>  #include <alloca.h>
> 

FYI, I stumbled on the same problem when building for various architectures this weekend.  I
generated some toolchains by using some of the Buildroot included configurations, which use
uclibc.  I ended up defining those macros as well in CFLAGS.  So that change can help for more
configurations than just mingw.

Re: [PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

[Simon Marchi]

On 15-11-02 03:47 PM, Simon Marchi wrote:
> FYI, I stumbled on the same problem when building for various architectures this weekend.  I
> generated some toolchains by using some of the Buildroot included configurations, which use
> uclibc.  I ended up defining those macros as well in CFLAGS.  So that change can help for more
> configurations than just mingw.

Actually, would it be better to add ifndefs?

#ifndef __STDC_CONSTANT_MACROS
#define __STDC_CONSTANT_MACROS
#endif

(same for __STDC_LIMIT_MACROS)

I tried to build the latest version of the branch, but since I had specified those in CFLAGS, I get:


In file included from /home/simark/src/binutils-gdb/gdb/defs.h:28:0,
                 from /home/simark/src/binutils-gdb/gdb/gdb.c:19:
/home/simark/src/binutils-gdb/gdb/common/common-defs.h:47:0: error: "__STDC_CONSTANT_MACROS" redefined [-Werror]
 #define __STDC_CONSTANT_MACROS
 ^
<command-line>:0:0: note: this is the location of the previous definition
In file included from /home/simark/src/binutils-gdb/gdb/defs.h:28:0,
                 from /home/simark/src/binutils-gdb/gdb/gdb.c:19:
/home/simark/src/binutils-gdb/gdb/common/common-defs.h:48:0: error: "__STDC_LIMIT_MACROS" redefined [-Werror]
 #define __STDC_LIMIT_MACROS
 ^
<command-line>:0:0: note: this is the location of the previous definition
cc1plus: all warnings being treated as errors

Re: [PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

[Pedro Alves]

On 11/03/2015 01:58 PM, Simon Marchi wrote:
> On 15-11-02 03:47 PM, Simon Marchi wrote:
>> FYI, I stumbled on the same problem when building for various architectures this weekend.  I
>> generated some toolchains by using some of the Buildroot included configurations, which use
>> uclibc.  I ended up defining those macros as well in CFLAGS.  So that change can help for more
>> configurations than just mingw.
> 
> Actually, would it be better to add ifndefs?
> 
> #ifndef __STDC_CONSTANT_MACROS
> #define __STDC_CONSTANT_MACROS
> #endif
> 
> (same for __STDC_LIMIT_MACROS)
> 
> I tried to build the latest version of the branch, but since I had specified those in CFLAGS, I get:

Isn't this a case of "don't do that (CFLAGS), then" ?

If I update the gnulib patch per Paul's comment here:

  https://lists.nongnu.org/archive/html/bug-gnulib/2015-11/msg00006.html

then __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS will be
unconditionally defined in config.h; I don't think defines
in config.h can be ifndefed.

Thanks,
Pedro Alves

Re: [PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

[Simon Marchi]

On 15-11-03 09:06 AM, Pedro Alves wrote:
> Isn't this a case of "don't do that (CFLAGS), then" ?

Maybe.  I was thinking somebody might have this defined in their
development environment, but I agree it's unlikely.

Re: [PATCH 07/11] [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for stdint.h

[Pedro Alves]

On 11/03/2015 02:15 PM, Simon Marchi wrote:
> On 15-11-03 09:06 AM, Pedro Alves wrote:
>> Isn't this a case of "don't do that (CFLAGS), then" ?
> 
> Maybe.  I was thinking somebody might have this defined in their
> development environment, but I agree it's unlikely.
> 

As discussed on irc, -DFOO actually gives the symbol value 1, so
Simon got the error because I had defined the symbols with no value, like:

#define __STDC_CONSTANT_MACROS

So if we define the symbols with value 1, then the error is gone.

Here's the updated patch.

-------
From a710518eff022b6ab452415ab1191dc5c748dfe5 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Sun, 1 Nov 2015 17:33:36 +0000
Subject: [PATCH] [C++/mingw] Define __STDC_CONSTANT_MACROS /
 __STDC_LIMIT_MACROS for stdint.h

Cross building for --host=x86_64-w64-mingw32 using Fedora 20's g++
(gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)), stumbles on
many instances of:

 In file included from ../../src/gdb/../include/splay-tree.h:43:0,
                  from ../../src/gdb/dcache.c:26:
 build-gnulib/import/inttypes.h:61:3: error: #error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
  # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
    ^
 make: *** [dcache.o] Error 1

That's:

 #if !(INT_MIN == INT32_MIN && INT_MAX == INT32_MAX)
 # error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
 #endif

The issue is that on some hosts that predate C++11, when using C++ one
must define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS to make visible
the definitions of INTMAX_C / INTMAX_MAX etc.

This was a C99 requirement that later C++11 -- the first to define
stdint.h -- removed, and then C11 removed it as well.

https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
says that gnulib's stdint.h fixes this, but because we run gnulib's
configure tests with a C compiler, gnulib determines that mingw's
stdint.h is C99-compliant, and doesn't actually replace it.  Actually,
even though configuring gnulib with a C++ compiler does result in
gnulib replacing stdint.h, the resulting replacement is broken for
mingw, because it defines uintptr_t incorrectly.  I sent a gnulib
patch upstream to fix that, here:

  https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html

but then even with that, gnulib still stumbles on other
configured-with-C++-compiler problems.

So for now, until gnulib + C++ is fixed upstream and then gdb's copy
is updated, which may take a while, I think it's best to keep
configuring gnulib in C, and define
__STDC_LIMIT_MACROS/__STDC_CONSTANT_MACROS ourselves, just like C99
intended.

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* common/common-defs.h (__STDC_CONSTANT_MACROS)
	(__STDC_LIMIT_MACROS): Define before including stdint.h.
---
 gdb/common/common-defs.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
index 2be0d7d..548fe42 100644
--- a/gdb/common/common-defs.h
+++ b/gdb/common/common-defs.h
@@ -31,7 +31,23 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <stddef.h>
+
+/* From:
+    https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
+
+   "On some hosts that predate C++11, when using C++ one must define
+   __STDC_CONSTANT_MACROS to make visible the definitions of constant
+   macros such as INTMAX_C, and one must define __STDC_LIMIT_MACROS to
+   make visible the definitions of limit macros such as INTMAX_MAX."
+
+   gnulib doesn't fix this for us correctly yet.  See:
+     https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
+
+   Meanwhile, explicitly define these ourselves, as C99 intended.  */
+#define __STDC_CONSTANT_MACROS 1
+#define __STDC_LIMIT_MACROS 1
 #include <stdint.h>
+
 #include <string.h>
 #include <errno.h>
 #include <alloca.h>
-- 
1.9.3

[PATCH 08/11] [C++/mingw] Simplify first chance exception handling

[Pedro Alves]

I can't figure out why we treat first chance exceptions any different
here.

We set last_sig to 1, and then call windows_resume passing signal==1,
so the DBG_EXCEPTION_NOT_HANDLED code path in win32_resume is taken:

~~~
  if (sig != GDB_SIGNAL_0)
    {
      if (current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT)
	{
	  OUTMSG (("Cannot continue with signal %d here.\n", sig));
	}
      else if (sig == last_sig)
	continue_status = DBG_EXCEPTION_NOT_HANDLED;
      else
	OUTMSG (("Can only continue with recieved signal %d.\n", last_sig));
    }
~~~

Fix this by removing this special casing.  gdbserver also goes
straight to continuing with DBG_EXCEPTION_NOT_HANDLED, AFAICS.

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* windows-nat.c (handle_exception): Return 0 for first chance
	exceptions.
	(get_windows_debug_event): Adjust.
---
 gdb/windows-nat.c | 24 ++++++------------------
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 2e12493..cfbd74a 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1124,7 +1124,7 @@ handle_exception (struct target_waitstatus *ourstatus)
     default:
       /* Treat unhandled first chance exceptions specially.  */
       if (current_event.u.Exception.dwFirstChance)
-	return -1;
+	return 0;
       printf_unfiltered ("gdb: unknown target exception 0x%08x at %s\n",
 	(unsigned) current_event.u.Exception.ExceptionRecord.ExceptionCode,
 	host_address_to_string (
@@ -1491,19 +1491,10 @@ get_windows_debug_event (struct target_ops *ops,
 		     "EXCEPTION_DEBUG_EVENT"));
       if (saw_create != 1)
 	break;
-      switch (handle_exception (ourstatus))
-	{
-	case 0:
-	  continue_status = DBG_EXCEPTION_NOT_HANDLED;
-	  break;
-	case 1:
-	  thread_id = current_event.dwThreadId;
-	  break;
-	case -1:
-	  last_sig = 1;
-	  continue_status = -1;
-	  break;
-	}
+      if (handle_exception (ourstatus))
+	thread_id = current_event.dwThreadId;
+      else
+	continue_status = DBG_EXCEPTION_NOT_HANDLED;
       break;
 
     case OUTPUT_DEBUG_STRING_EVENT:	/* Message from the kernel.  */
@@ -1529,10 +1520,7 @@ get_windows_debug_event (struct target_ops *ops,
 
   if (!thread_id || saw_create != 1)
     {
-      if (continue_status == -1)
-	windows_resume (ops, minus_one_ptid, 0, 1);
-      else
-	CHECK (windows_continue (continue_status, -1, 0));
+      CHECK (windows_continue (continue_status, -1, 0));
     }
   else
     {
-- 
1.9.3

Re: [PATCH 08/11] [C++/mingw] Simplify first chance exception handling

[Simon Marchi]

On 15-11-02 02:36 PM, Pedro Alves wrote:
> I can't figure out why we treat first chance exceptions any different
> here.
> 
> We set last_sig to 1, and then call windows_resume passing signal==1,
> so the DBG_EXCEPTION_NOT_HANDLED code path in win32_resume is taken:
> 
> ~~~
>   if (sig != GDB_SIGNAL_0)
>     {
>       if (current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT)
> 	{
> 	  OUTMSG (("Cannot continue with signal %d here.\n", sig));
> 	}
>       else if (sig == last_sig)
> 	continue_status = DBG_EXCEPTION_NOT_HANDLED;
>       else
> 	OUTMSG (("Can only continue with recieved signal %d.\n", last_sig));
>     }
> ~~~
> 
> Fix this by removing this special casing.  gdbserver also goes
> straight to continuing with DBG_EXCEPTION_NOT_HANDLED, AFAICS.
> 
> gdb/ChangeLog:
> 2015-11-01  Pedro Alves  <palves@redhat.com>
> 
> 	* windows-nat.c (handle_exception): Return 0 for first chance
> 	exceptions.
> 	(get_windows_debug_event): Adjust.
> ---
>  gdb/windows-nat.c | 24 ++++++------------------
>  1 file changed, 6 insertions(+), 18 deletions(-)
> 
> diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
> index 2e12493..cfbd74a 100644
> --- a/gdb/windows-nat.c
> +++ b/gdb/windows-nat.c
> @@ -1124,7 +1124,7 @@ handle_exception (struct target_waitstatus *ourstatus)
>      default:
>        /* Treat unhandled first chance exceptions specially.  */
>        if (current_event.u.Exception.dwFirstChance)
> -	return -1;
> +	return 0;
>        printf_unfiltered ("gdb: unknown target exception 0x%08x at %s\n",
>  	(unsigned) current_event.u.Exception.ExceptionRecord.ExceptionCode,
>  	host_address_to_string (
> @@ -1491,19 +1491,10 @@ get_windows_debug_event (struct target_ops *ops,
>  		     "EXCEPTION_DEBUG_EVENT"));
>        if (saw_create != 1)
>  	break;
> -      switch (handle_exception (ourstatus))
> -	{
> -	case 0:
> -	  continue_status = DBG_EXCEPTION_NOT_HANDLED;
> -	  break;
> -	case 1:
> -	  thread_id = current_event.dwThreadId;
> -	  break;
> -	case -1:
> -	  last_sig = 1;
> -	  continue_status = -1;
> -	  break;
> -	}
> +      if (handle_exception (ourstatus))
> +	thread_id = current_event.dwThreadId;
> +      else
> +	continue_status = DBG_EXCEPTION_NOT_HANDLED;
>        break;
>  
>      case OUTPUT_DEBUG_STRING_EVENT:	/* Message from the kernel.  */
> @@ -1529,10 +1520,7 @@ get_windows_debug_event (struct target_ops *ops,
>  
>    if (!thread_id || saw_create != 1)
>      {
> -      if (continue_status == -1)
> -	windows_resume (ops, minus_one_ptid, 0, 1);
> -      else
> -	CHECK (windows_continue (continue_status, -1, 0));
> +      CHECK (windows_continue (continue_status, -1, 0));
>      }
>    else
>      {
> 

Does this change fix something initially related to C++?

Re: [PATCH 08/11] [C++/mingw] Simplify first chance exception handling

[Pedro Alves]

On 11/02/2015 09:01 PM, Simon Marchi wrote:

> Does this change fix something initially related to C++?

Whoops, forgot to mention that in the commit log.  Now updated.

From b2759c57612aa28d19b140a7edf5bac57982564b Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 30 Oct 2015 20:49:06 +0000
Subject: [PATCH] [C++/mingw] Simplify first chance exception handling

Building in C++ errors out with:

../../src/gdb/windows-nat.c: In function 'int get_windows_debug_event(target_ops*, int, target_waitstatus*)':
../../src/gdb/windows-nat.c:1503:13: warning: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
    last_sig = 1;
             ^
../../src/gdb/windows-nat.c:1533:43: warning: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
  windows_resume (ops, minus_one_ptid, 0, 1);
                                           ^
../../src/gdb/windows-nat.c:1228:1: warning:   initializing argument 4 of 'void windows_resume(target_ops*, ptid_t, int, gdb_signal)' [-fpermissive]
 windows_resume (struct target_ops *ops,
 ^

Looking at the code, I can't figure out why we treat first chance
exceptions any different here.

AFAICS, we set last_sig to 1, and then call windows_resume passing
signal==1, so the DBG_EXCEPTION_NOT_HANDLED code path in win32_resume
is taken:

~~~
  if (sig != GDB_SIGNAL_0)
    {
      if (current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT)
	{
	  OUTMSG (("Cannot continue with signal %d here.\n", sig));
	}
      else if (sig == last_sig)
	continue_status = DBG_EXCEPTION_NOT_HANDLED;
      else
	OUTMSG (("Can only continue with recieved signal %d.\n", last_sig));
    }
~~~

Fix this by removing this special casing.  gdbserver also goes
straight to continuing with DBG_EXCEPTION_NOT_HANDLED, AFAICS.

gdb/ChangeLog:
2015-11-01  Pedro Alves  <palves@redhat.com>

	* windows-nat.c (handle_exception): Return 0 for first chance
	exceptions.
	(get_windows_debug_event): Adjust.
---
 gdb/windows-nat.c | 24 ++++++------------------
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index cce10f8..a7132d6 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1124,7 +1124,7 @@ handle_exception (struct target_waitstatus *ourstatus)
     default:
       /* Treat unhandled first chance exceptions specially.  */
       if (current_event.u.Exception.dwFirstChance)
-	return -1;
+	return 0;
       printf_unfiltered ("gdb: unknown target exception 0x%08x at %s\n",
 	(unsigned) current_event.u.Exception.ExceptionRecord.ExceptionCode,
 	host_address_to_string (
@@ -1491,19 +1491,10 @@ get_windows_debug_event (struct target_ops *ops,
 		     "EXCEPTION_DEBUG_EVENT"));
       if (saw_create != 1)
 	break;
-      switch (handle_exception (ourstatus))
-	{
-	case 0:
-	  continue_status = DBG_EXCEPTION_NOT_HANDLED;
-	  break;
-	case 1:
-	  thread_id = current_event.dwThreadId;
-	  break;
-	case -1:
-	  last_sig = 1;
-	  continue_status = -1;
-	  break;
-	}
+      if (handle_exception (ourstatus))
+	thread_id = current_event.dwThreadId;
+      else
+	continue_status = DBG_EXCEPTION_NOT_HANDLED;
       break;
 
     case OUTPUT_DEBUG_STRING_EVENT:	/* Message from the kernel.  */
@@ -1529,10 +1520,7 @@ get_windows_debug_event (struct target_ops *ops,
 
   if (!thread_id || saw_create != 1)
     {
-      if (continue_status == -1)
-	windows_resume (ops, minus_one_ptid, 0, 1);
-      else
-	CHECK (windows_continue (continue_status, -1, 0));
+      CHECK (windows_continue (continue_status, -1, 0));
     }
   else
     {
-- 
1.9.3

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/02/2015 07:35 PM, Pedro Alves wrote:
> I tried cross building gdb for --host=x86_64-w64-mingw32 using Fedora
> 20's g++ (gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)).
> 
> This fixes all issues I found which aren't already sorted in the C++
> branch and/or have fixes already posted.
> 
> This is only build-tested.

BTW, I pushed a testable tree to users/palves/mingw-cxx-conversion, in
case someone could lend a hand with running gdb / testing on Windows.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro,

On Tue, Nov 3, 2015 at 4:05 AM, Pedro Alves <palves@redhat.com> wrote:
> BTW, I pushed a testable tree to users/palves/mingw-cxx-conversion, in
> case someone could lend a hand with running gdb / testing on Windows.

Thanks for your work, I'll run gdb and test on both Windows and Wine
this weekend.

BTW, there was a bug report of test failure found by running gdb /
binutils testsuite on Windows:
https://sourceware.org/bugzilla/show_bug.cgi?id=19052

No one has comment on that bug yet, did we report to the wrong component?

Thanks!


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

[+Iain]

On 11/02/2015 08:22 PM, Qian Hong wrote:
> Hi Pedro,
> 
> On Tue, Nov 3, 2015 at 4:05 AM, Pedro Alves <palves@redhat.com> wrote:
>> BTW, I pushed a testable tree to users/palves/mingw-cxx-conversion, in
>> case someone could lend a hand with running gdb / testing on Windows.
> 
> Thanks for your work, I'll run gdb and test on both Windows and Wine
> this weekend.

Thanks!  Note you'll need to configure gdb with --enable-build-with-cxx
in order to make it build with a C++ compiler.

> 
> BTW, there was a bug report of test failure found by running gdb /
> binutils testsuite on Windows:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19052
> 
> No one has comment on that bug yet, did we report to the wrong component?

I suspect that nobody is really actively paying attention to Windows bugs
in bugzilla... :-/

That said, this sounds like a demangler testsuite issue.  GDB is not involved.

Iain, this is:

./test-demangle < ../../../gdb-7.10/libiberty/testsuite/d-demangle-expected
FAIL at line 750, options --format=dlang:
in:  _D8demangle23__T4testVfe0FFFFFFP128Zv
out: demangle.test!(3.40282e+038)
exp: demangle.test!(3.40282e+38)
FAIL at line 758, options --format=dlang:
in:  _D8demangle19__T4testVfe08PN125Zv
out: demangle.test!(1.17549e-038)
exp: demangle.test!(1.17549e-38)
E:\MINGW-packages\mingw-w64-gdb\src\build-i686-w64-mingw32\libiberty\testsuite\test-demangle.exe: 266 tests, 2 failures

It just looks like msvcrt.dll's printf prints using an
unexpected format?  Maybe building the test program with
__USE_MINGW_ANSI_STDIO defined fixes it.  Could you try that?

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro, thanks a lot for the reply!

On Tue, Nov 3, 2015 at 4:46 AM, Pedro Alves <palves@redhat.com> wrote:
> It just looks like msvcrt.dll's printf prints using an
> unexpected format?  Maybe building the test program with
> __USE_MINGW_ANSI_STDIO defined fixes it.  Could you try that?


Yes, msvcrt.dll's printf has a different format than gcc Linux.
I just tried your suggestion but it doesn't make a change, later then
I use __mingw_printf to write a small test case, and found MinGW also
emulate msvcrt's format.

#include <stdio.h>
int main()
{
    double x = 3.40282e+038;
    __mingw_printf("%.5e\n", x);
}

$ i686-w64-mingw32-gcc  test2.c -o test2.exe

$ wine test2.exe # same result on Windows, just tested
3.40282e+038


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/02/2015 09:16 PM, Qian Hong wrote:

> $ wine test2.exe # same result on Windows, just tested
> 3.40282e+038

Oh well.

I think we're good already though -- I think Iain already fixed
this on master a while ago.  See 30379291886a171e6dc202122bc1c583318c2e17.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

On Tue, Nov 3, 2015 at 7:31 AM, Pedro Alves <palves@redhat.com> wrote:
> I think we're good already though -- I think Iain already fixed
> this on master a while ago.  See 30379291886a171e6dc202122bc1c583318c2e17.


Confirming fixed, thank you!



-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro,

On Tue, Nov 3, 2015 at 4:46 AM, Pedro Alves <palves@redhat.com> wrote:
> Thanks!  Note you'll need to configure gdb with --enable-build-with-cxx
> in order to make it build with a C++ compiler.

I think I have some interesting testing result for you ;-)

I compiled latest gdb in your branch on MSYS2 on Windows [1], with my
additional modification to enable build-with-cxx.

It compiles fine. However, when debugging a simple hello world
program, I got error below:
"This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information." when debugging a simple hello world program. "

Steps to reproduce:
1. $ cat hello.c
# include <stdio.h>
int main(void)
{
    int a = 10;
    printf("haha a is %d\n", 10);
    return 0;
}

2. compile with MSYS2 mingw gcc
$ gcc hello.c -g -O0 -o hello.exe

3. debugging hello.exe with gdb (build with cxx)
$ gdb hello.exe

3.1. set a breakpoint on main()
3.2. type `c`

expect result:
gdb should report that the program is not start yet.

actual result:
gdb exit with error message: "This application has requested the
Runtime to terminate it in an unusual way. Please contact the
application's support team for more information." when debugging a
simple hello world program. "

Then I tried build gdb again without build-with-cxx, and this error
disappear, gdb works as expect, at least for simple hello world.

Cross-reference: feature request for gdb-git package in MSYS2 [2]

[1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdb-git
[2] https://github.com/Alexpux/MINGW-packages/issues/862



-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

On Tue, Nov 3, 2015 at 6:46 PM, Qian Hong <fracting@gmail.com> wrote:
> actual result:
> gdb exit with error message: "This application has requested the
> Runtime to terminate it in an unusual way. Please contact the
> application's support team for more information." when debugging a
> simple hello world program. "


Update:

I also test it on Wine, for your convenient, if you don't have Windows
nearby to test, maybe Wine is an option.

I tested with Wine Staging 1.7.53, which provides prebuilt binaries to
mainstream Linux distributions [1].

The test result is almost the same between Windows and Wine: gcc build
of gdb works fine, g++ build of gdb broken.
The exit status is 0x3, the same on Windows and Wine.

I tried use WineDbg to debug gdb, but I found there is no backtrace at failure.

(However, for unknown reason, Wine doesn't print the error message
"This application has requested ... ", I'll look into that later,
should be a Wine bug.)



[1] https://github.com/wine-compholio/wine-staging/wiki/Installation

-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 11:14 AM, Qian Hong wrote:
> On Tue, Nov 3, 2015 at 6:46 PM, Qian Hong <fracting@gmail.com> wrote:
>> actual result:
>> gdb exit with error message: "This application has requested the
>> Runtime to terminate it in an unusual way. Please contact the
>> application's support team for more information." when debugging a
>> simple hello world program. "
> 
> 
> Update:
> 
> I also test it on Wine, for your convenient, if you don't have Windows
> nearby to test, maybe Wine is an option.

I've actually tried Wine multiple times before over the years.  I've managed
to run gdbserver under Wine (in the past, haven't tried recently), and connect
to it with a GNU/Linux-hosted cross debugger (--host=linux --target=mingw),
but gdb running under Wine has never worked for me.  The problem for
me is that input does not work.

> 
> I tested with Wine Staging 1.7.53, which provides prebuilt binaries to
> mainstream Linux distributions [1].

Using Wine Staging 1.7.51 I get:

$ ./gdb.exe
fixme:winediag:start_process Wine Staging 1.7.51 is a testing version containing experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com (instead of winehq.org).
Z:\home\pedro\gdb\mygit\cxx-convertion\build-c-mingw\gdb\gdb.exe: warning: cannot automatically find executable file or library to read symbols.
Use "file" or "dll" command to load executable/libraries directly.
GNU gdb (GDB) 7.10.50.20151029-cvs
Copyright (C) 2015 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 "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
p 1


^CQuit
(gdb) bt


^CQuit
(gdb


Those brank lines are me pressing enter.  Seems like the newline/input never
reaches gdb.  ctrl-c does work, as can be seen by the "Quit"s.

This is on Fedora 20.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro,

Thanks for testing Wine Staging.

On Tue, Nov 3, 2015 at 7:26 PM, Pedro Alves <palves@redhat.com> wrote:
> I've actually tried Wine multiple times before over the years.  I've managed
> to run gdbserver under Wine (in the past, haven't tried recently), and connect
> to it with a GNU/Linux-hosted cross debugger (--host=linux --target=mingw),
> but gdb running under Wine has never worked for me.  The problem for
> me is that input does not work.

I can confirm the behavior you described.

I think this is related to a known bug I want to fix:
https://bugs.wine-staging.com/show_bug.cgi?id=290

At this time, there is two solution to make input works.

Solution A: start wineconsole before using gdb:
$ wineconsole

C:\path\to\gdb.exe

Solution B: use MinTTY as a replacement of wineconsole, from MSYS2
project: https://msys2.github.io/
(note: `export STAGING_WRITECOPY=1` is required before using MSYS2,
see https://github.com/fracting/wine-fracting/wiki/MSYS2-on-Wine#build-status
)

The advantage of solution A is, no third party software required,
however, the disadvantage is, wineconsole itself is not nice, things
like copy&paste doesn't work, it is not a good terminal emulator in
practice. The advantage of solution B is, mintty is a full working
terminal emulator, also with some tweaking we can use Linux like
shortcut (ctrl+shift+c/v) inside mintty, in addition there are a
couple of other GNU/Linux tools available in MSYS2 repo, but the
disadvantage is we need to install third party software ;-)

If you have chance to try either wineconsole or mintty, please let me
know if it solve your input, that's great appreciated.




-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

On Tue, Nov 3, 2015 at 7:40 PM, Qian Hong <fracting@gmail.com> wrote:
> Solution B: use MinTTY as a replacement of wineconsole, from MSYS2
> project: https://msys2.github.io/
> (note: `export STAGING_WRITECOPY=1` is required before using MSYS2,
> see https://github.com/fracting/wine-fracting/wiki/MSYS2-on-Wine#build-status
> )

Sorry, wrong hash.
Should be https://github.com/fracting/wine-fracting/wiki/MSYS2-on-Wine#install-msys2
instead.


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 11:40 AM, Qian Hong wrote:
> Hi Pedro,
> 
> Thanks for testing Wine Staging.
> 
> On Tue, Nov 3, 2015 at 7:26 PM, Pedro Alves <palves@redhat.com> wrote:
>> I've actually tried Wine multiple times before over the years.  I've managed
>> to run gdbserver under Wine (in the past, haven't tried recently), and connect
>> to it with a GNU/Linux-hosted cross debugger (--host=linux --target=mingw),
>> but gdb running under Wine has never worked for me.  The problem for
>> me is that input does not work.
> 
> I can confirm the behavior you described.
> 
> I think this is related to a known bug I want to fix:
> https://bugs.wine-staging.com/show_bug.cgi?id=290
> 
> At this time, there is two solution to make input works.
> 
> Solution A: start wineconsole before using gdb:
> $ wineconsole
> 
> C:\path\to\gdb.exe
> 
> Solution B: use MinTTY as a replacement of wineconsole, from MSYS2
> project: https://msys2.github.io/
> (note: `export STAGING_WRITECOPY=1` is required before using MSYS2,
> see https://github.com/fracting/wine-fracting/wiki/MSYS2-on-Wine#build-status
> )
> 
> The advantage of solution A is, no third party software required,
> however, the disadvantage is, wineconsole itself is not nice, things
> like copy&paste doesn't work, it is not a good terminal emulator in
> practice. The advantage of solution B is, mintty is a full working
> terminal emulator, also with some tweaking we can use Linux like
> shortcut (ctrl+shift+c/v) inside mintty, in addition there are a
> couple of other GNU/Linux tools available in MSYS2 repo, but the
> disadvantage is we need to install third party software ;-)
> 
> If you have chance to try either wineconsole or mintty, please let me
> know if it solve your input, that's great appreciated.

Thanks!  I'll try this when I have a chance.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 10:46 AM, Qian Hong wrote:
> Hi Pedro,
> 
> On Tue, Nov 3, 2015 at 4:46 AM, Pedro Alves <palves@redhat.com> wrote:
>> Thanks!  Note you'll need to configure gdb with --enable-build-with-cxx
>> in order to make it build with a C++ compiler.
> 
> I think I have some interesting testing result for you ;-)
> 
> I compiled latest gdb in your branch on MSYS2 on Windows [1], with my
> additional modification to enable build-with-cxx.
> 
> It compiles fine. However, when debugging a simple hello world
> program, I got error below:
> "This application has requested the Runtime to terminate it in an
> unusual way. Please contact the application's support team for more
> information." when debugging a simple hello world program. "
> 
> Steps to reproduce:
> 1. $ cat hello.c
> # include <stdio.h>
> int main(void)
> {
>     int a = 10;
>     printf("haha a is %d\n", 10);
>     return 0;
> }
> 
> 2. compile with MSYS2 mingw gcc
> $ gcc hello.c -g -O0 -o hello.exe
> 
> 3. debugging hello.exe with gdb (build with cxx)
> $ gdb hello.exe
> 
> 3.1. set a breakpoint on main()
> 3.2. type `c`
> 
> expect result:
> gdb should report that the program is not start yet.
> 
> actual result:
> gdb exit with error message: "This application has requested the
> Runtime to terminate it in an unusual way. Please contact the
> application's support team for more information." when debugging a
> simple hello world program. "

Hmm.  Sounds like an uncaught C++ exception.   I guess we could try
making C++ mode use setjmp/longjmp exceptions like C mode, for confirmation.

> 
> Then I tried build gdb again without build-with-cxx, and this error
> disappear, gdb works as expect, at least for simple hello world.
> 
> Cross-reference: feature request for gdb-git package in MSYS2 [2]
> 
> [1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdb-git
> [2] https://github.com/Alexpux/MINGW-packages/issues/862
> 
> 
> 


Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 11:20 AM, Pedro Alves wrote:
> On 11/03/2015 10:46 AM, Qian Hong wrote:

>> actual result:
>> gdb exit with error message: "This application has requested the
>> Runtime to terminate it in an unusual way. Please contact the
>> application's support team for more information." when debugging a
>> simple hello world program. "
> 
> Hmm.  Sounds like an uncaught C++ exception.   I guess we could try
> making C++ mode use setjmp/longjmp exceptions like C mode, for confirmation.
> 
>>
>> Then I tried build gdb again without build-with-cxx, and this error
>> disappear, gdb works as expect, at least for simple hello world.

I've pushed this patch:

  https://sourceware.org/ml/gdb-patches/2015-11/msg00114.html

on the testing branch as well.  I wonder if it makes a difference for you.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Thanks for the work!

On Wed, Nov 4, 2015 at 12:54 AM, Pedro Alves <palves@redhat.com> wrote:
> on the testing branch as well.  I wonder if it makes a difference for you.

Update 1: yes, the printf patch fix the build for me.
Update 2: since I was unable to build un-patched gdb, I didn't tested
un-patched gdb before. Now I found un-patched gdb works out of box, no
matter whether --enable-build-with-cxx is set, no matter whether the
setjmp patch is applied.
Update 3: However, when testing gdb with third party patches from
MSYS2 project, the gcc build is fine, but the g++ build is broken, no
matter whether the setjmp patch is applied.

I'll continue work with MSYS2 maintainer to investigate further before
bother you too much, but in case you are interesting please also feel
free to subscribe https://github.com/Alexpux/MINGW-packages/issues/862

Once we fix MSYS2 mingw-w64 gdb package, I'll report back again, and
let's see if there is any patch worth to upstream here then.

Thank you and have a good day!


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

On Wed, Nov 4, 2015 at 12:54 AM, Pedro Alves <palves@redhat.com> wrote:
> I've pushed this patch:
>
>   https://sourceware.org/ml/gdb-patches/2015-11/msg00114.html
>
> on the testing branch as well.  I wonder if it makes a difference for you.

Update:

I can confirm this patch fix the issue for MSYS2 mingw-w64 gdb.

I was testing the wrong binary due to frequently switch between
Windows VM and Linux host.
Sorry for the stupid mistake and noise.

Thanks for the fix!


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 09:02 PM, Qian Hong wrote:
> On Wed, Nov 4, 2015 at 12:54 AM, Pedro Alves <palves@redhat.com> wrote:
>> I've pushed this patch:
>>
>>   https://sourceware.org/ml/gdb-patches/2015-11/msg00114.html
>>
>> on the testing branch as well.  I wonder if it makes a difference for you.
> 
> Update:
> 
> I can confirm this patch fix the issue for MSYS2 mingw-w64 gdb.
> 
> I was testing the wrong binary due to frequently switch between
> Windows VM and Linux host.
> Sorry for the stupid mistake and noise.

No worries, and thanks for reconfirming.

Note however, that the patch will be reverted at some point.  It's
a workaround until we get rid of exceptions thrown from signal
handlers, but, Windows doesn't really have unix-like async signal
handlers (signal handlers run on a separate thread), so it should
be unaffected by that issue.

From the backtrace you showed:

(gdb) bt
#0  0x00870778 in abort ()
#1  0x0085ebda in uw_init_context_1 ()
#2  0x0085f2de in _Unwind_RaiseException ()
#3  0x008728e5 in __cxa_throw ()
#4  0x006cfead in throw_exception (exception=...)
    at ../../gdb/gdb/common/common-exceptions.c:295
#5  0x006d000d in throw_it (reason=RETURN_ERROR, error=GENERIC_ERROR,
    fmt=0x8d86bc <filename_display_kind_names+52> "No symbol table is loaded.  Use the \"file\" command.", ap=0x320f754 "~aP")
    at ../../gdb/gdb/common/common-exceptions.c:354
#6  0x006d0034 in throw_verror (error=GENERIC_ERROR,
    fmt=0x8d86bc <filename_display_kind_names+52> "No symbol table is loaded.  Use the \"file\" command.", ap=0x320f754 "~aP")
    at ../../gdb/gdb/common/common-exceptions.c:360
#7  0x0068c1f6 in verror (
    string=<error reading variable: Could not find the frame base for "verror(char const*, char*)".>,
    args=<error reading variable: Could not find the frame base for "verror(char const*, char*)".>) at ../../gdb/gdb/utils.c:525
#8  0x006cfc77 in error (
    fmt=0x8d86bc <filename_display_kind_names+52> "No symbol table is loaded.  Use the \"file\" command.") at ../../gdb/gdb/common/errors.c:43
#9  0x0050c964 in set_default_source_symtab_and_line ()
    at ../../gdb/gdb/source.c:207
#10 0x00474fa0 in list_command (
...

We see that gdb was throwing a gdb exception from mainline code,
not a signal handler, and in frame #4, gdb called the runtime to throw
the (underlying) C++ exception.  Line common-exceptions.c:295 is just "throw ex;"

So it seems to me that something is wrong with C++ exceptions
support in the mingw toolchain you used.  I suggest trying a simple
test like:

int
main ()
{
  try
    {
      throw 1;
    }
  catch(...)
    {
    }

  return 0;
}

... to check whether C++ exceptions work at all.

One issue to look out for is what flavor of C++ exceptions your mingw
toolchain uses.  There are flavors using dwarf2, others using sjlj.  Also, we
link gdb with -static-libstdc++ -static-libgcc, which may make a difference.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro,

Thanks for the info, I did some tests with your code.

On Wed, Nov 4, 2015 at 6:39 AM, Pedro Alves <palves@redhat.com> wrote:
> So it seems to me that something is wrong with C++ exceptions
> support in the mingw toolchain you used.  I suggest trying a simple
> test like:
>
> int
> main ()
> {
>   try
>     {
>       throw 1;
>     }
>   catch(...)
>     {
>     }
>
>   return 0;
> }
>
> ... to check whether C++ exceptions work at all.

The above test case works for me.
I tried several thing:
1. build the above code with MINGW-w64 g++ from MSYS2, run on MSYS2.
It works on both Windows and Wine.
2. build the above code with MinGW-w64 cross compiler from my Ubuntu,
runs on Wine, works as expected.
3. build the above code with Linux native g++ (i386), runs on Linux,
works as expected.
4. Added customer printf statement to the source code, retest on all
configuration above, and I can confirm all executed code path are the
same.


> One issue to look out for is what flavor of C++ exceptions your mingw
> toolchain uses.  There are flavors using dwarf2, others using sjlj.  Also, we
> link gdb with -static-libstdc++ -static-libgcc, which may make a difference.

I tried all 4 combination of with/without
-static-libstdc++/-static-libgcc, the test case works for me on
Windows with MinGW-w64 g++ from MSYS2.

MSYS2 g++ has --disable-sjlj-exceptions --with-dwarf2, not sure if it
does matter.


Here is the MinGW-w64 g++ provided by MSYS2:
Using built-in specs.
COLLECT_GCC=E:\msys32\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=E:/msys32/mingw32/bin/../lib/gcc/i686-w64-mingw32/5.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-5.2.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/i686-w64-mingw32/include
--libexecdir=/mingw32/lib
--with-gxx-include-dir=/mingw32/include/c++/5.2.0 --enable-bootstrap
--with-arch=i686 --with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-version-specific-runtime-libs
--disable-isl-version-check --enable-lto --enable-libgomp
--disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/mingw32 --with-mpfr=/mingw32 --with-mpc=/mingw32
--with-isl=/mingw32 --with-pkgversion='Rev4, Built by MSYS2 project'
--with-bugurl=http://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld --disable-sjlj-exceptions --with-dwarf2
Thread model: posix
gcc version 5.2.0 (Rev4, Built by MSYS2 project)

I've forwarded the question to MSYS2 maintainers in #msys2 (OFTC),
will update once I have more information.

Thanks!


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/09/2015 09:52 AM, Qian Hong wrote:
> Hi Pedro,
> 

Hi Qian,

> Thanks for the info, I did some tests with your code.
> 
> On Wed, Nov 4, 2015 at 6:39 AM, Pedro Alves <palves@redhat.com> wrote:
>> So it seems to me that something is wrong with C++ exceptions
>> support in the mingw toolchain you used.  I suggest trying a simple
>> test like:
>>

>>
>> ... to check whether C++ exceptions work at all.
> 
> The above test case works for me.
> I tried several thing:
> 1. build the above code with MINGW-w64 g++ from MSYS2, run on MSYS2.
> It works on both Windows and Wine.
> 2. build the above code with MinGW-w64 cross compiler from my Ubuntu,
> runs on Wine, works as expected.
> 3. build the above code with Linux native g++ (i386), runs on Linux,
> works as expected.
> 4. Added customer printf statement to the source code, retest on all
> configuration above, and I can confirm all executed code path are the
> same.
> 
> 
>> One issue to look out for is what flavor of C++ exceptions your mingw
>> toolchain uses.  There are flavors using dwarf2, others using sjlj.  Also, we
>> link gdb with -static-libstdc++ -static-libgcc, which may make a difference.
> 
> I tried all 4 combination of with/without
> -static-libstdc++/-static-libgcc, the test case works for me on
> Windows with MinGW-w64 g++ from MSYS2.
> 
> MSYS2 g++ has --disable-sjlj-exceptions --with-dwarf2, not sure if it
> does matter.

Could well be.  The problem may be that a dwarf or seh exception
(not sure which is used nowadays, if sjlj exceptions are disabled)
is failing to cross some foreign frame (e.g., a system DLL).
A C++ gdb cross built with Fedora 20's mingw-w64 g++ (4.8.4) runs fine
on a Windows 7 machine I had handy here, and that doesn't seem to
have been built with --disable-sjlj-exceptions.

Since C mode still works fine after my patches, and I can't imagine that it's
this series that's creating the exceptions/C++ issue you're running into, I'm
going ahead with pushing the series in.  We'll revisit later when we re-wire
THROW/CATCH to real C++ exceptions later on, if necessary.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro,

On Tue, Nov 17, 2015 at 10:50 PM, Pedro Alves <palves@redhat.com> wrote:
> Since C mode still works fine after my patches, and I can't imagine that it's
> this series that's creating the exceptions/C++ issue you're running into, I'm
> going ahead with pushing the series in.  We'll revisit later when we re-wire
> THROW/CATCH to real C++ exceptions later on, if necessary.

Sorry for long delay.
I communicated with MSYS2 developers, alexey told me he has no time to
look at it deeper soon, so I didn't go farther.
Thank you for the work, I'll put this issue on my todo list and keep
monitoring the list. If there is any interesting thing found I'll
start a new thread. If there is new patch to test on Windows/Wine I'll
also be glad to help.


-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/30/2015 03:02 PM, Qian Hong wrote:
> Hi Pedro,
> 
> On Tue, Nov 17, 2015 at 10:50 PM, Pedro Alves <palves@redhat.com> wrote:
>> Since C mode still works fine after my patches, and I can't imagine that it's
>> this series that's creating the exceptions/C++ issue you're running into, I'm
>> going ahead with pushing the series in.  We'll revisit later when we re-wire
>> THROW/CATCH to real C++ exceptions later on, if necessary.
> 
> Sorry for long delay.
> I communicated with MSYS2 developers, alexey told me he has no time to
> look at it deeper soon, so I didn't go farther.
> Thank you for the work, I'll put this issue on my todo list and keep
> monitoring the list. If there is any interesting thing found I'll
> start a new thread. If there is new patch to test on Windows/Wine I'll
> also be glad to help.

Alright, thanks for the update.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

Hi Pedro,

I found the below error when cross compile with `./configure
--host=i686-w64-mingw32 --enable-build-with-cxx`:

objcopy.c: In function ‘parse_symflags’:
objcopy.c:792:7: error: implicit declaration of function ‘strndup’
[-Werror=implicit-function-declaration]
       PARSE_OTHER ("before=", *other);
       ^
objcopy.c:774:9: error: incompatible implicit declaration of built-in
function ‘strndup’ [-Werror]
  fval = strndup (s + sizeof fname - 1, len - sizeof fname + 1)
         ^
objcopy.c:792:7: note: in expansion of macro ‘PARSE_OTHER’
       PARSE_OTHER ("before=", *other);
       ^
objcopy.c: In function ‘copy_main’:
objcopy.c:4085:23: error: incompatible implicit declaration of
built-in function ‘strndup’ [-Werror]
      newsym->symdef = strndup (optarg, s - optarg);
                       ^
cc1: all warnings being treated as errors
Makefile:939: recipe for target 'objcopy.o' failed
make[4]: *** [objcopy.o] Error 1

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 12:24 PM, Qian Hong wrote:
> Hi Pedro,
> 
> I found the below error when cross compile with `./configure
> --host=i686-w64-mingw32 --enable-build-with-cxx`:

Does it trigger without --enable-build-with-cxx as well?

> 
> objcopy.c: In function ‘parse_symflags’:
> objcopy.c:792:7: error: implicit declaration of function ‘strndup’
> [-Werror=implicit-function-declaration]
>        PARSE_OTHER ("before=", *other);
>        ^
> objcopy.c:774:9: error: incompatible implicit declaration of built-in
> function ‘strndup’ [-Werror]
>   fval = strndup (s + sizeof fname - 1, len - sizeof fname + 1)
>          ^
> objcopy.c:792:7: note: in expansion of macro ‘PARSE_OTHER’
>        PARSE_OTHER ("before=", *other);
>        ^
> objcopy.c: In function ‘copy_main’:
> objcopy.c:4085:23: error: incompatible implicit declaration of
> built-in function ‘strndup’ [-Werror]
>       newsym->symdef = strndup (optarg, s - optarg);
>                        ^
> cc1: all warnings being treated as errors
> Makefile:939: recipe for target 'objcopy.o' failed
> make[4]: *** [objcopy.o] Error 1
> 

... because binutils/objcopy.c is part of binutils, not gdb.  Is it
trying to build with a C++ compiler?  (doesn't look like that's
the issue, but ...)

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

On Tue, Nov 3, 2015 at 8:27 PM, Pedro Alves <palves@redhat.com> wrote:
> Does it trigger without --enable-build-with-cxx as well?

Yes, same error without build-with-cxx. So it is not related to c++ compiler.
strndup is not defined in mingw-w64...

I tried `make all-gdb` instead of `make all`, now new error found:
http://pastebin.com/rM7V7msA

I guess this is fixed by one of patches in
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdb-git

Would you mind have a look? Maybe some of MSYS2 patch could be pick
into your tree?

Thanks!



-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 12:56 PM, Qian Hong wrote:
> On Tue, Nov 3, 2015 at 8:27 PM, Pedro Alves <palves@redhat.com> wrote:
>> Does it trigger without --enable-build-with-cxx as well?
> 
> Yes, same error without build-with-cxx. So it is not related to c++ compiler.
> strndup is not defined in mingw-w64...

Thanks for confirming.  The ultimate test is confirming whether
pristine master builds, although I'm positive it'd fail as well.

> 
> I tried `make all-gdb` instead of `make all`, now new error found:
> http://pastebin.com/rM7V7msA
> 
> I guess this is fixed by one of patches in
> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdb-git
> 
> Would you mind have a look? Maybe some of MSYS2 patch could be pick
> into your tree?

Sorry, these patches need to be submitted to the relevant lists (we can't
just pull them, due to copyright assignment requirements), along with
rationale for them.  The binutils/ subdir is maintained by the binutils
team.  libiberty/ by the GCC folks.  See the top level MAINTAINTERS file
for the full mapping.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Qian Hong]

On Tue, Nov 3, 2015 at 9:08 PM, Pedro Alves <palves@redhat.com> wrote:
> Sorry, these patches need to be submitted to the relevant lists (we can't
> just pull them, due to copyright assignment requirements), along with
> rationale for them.  The binutils/ subdir is maintained by the binutils
> team.  libiberty/ by the GCC folks.  See the top level MAINTAINTERS file
> for the full mapping.

Understand, thanks.

> BTW, this patch should fix the error in the pastebin above:

> https://sourceware.org/ml/gdb-patches/2015-10/msg00733.html

Hmm, could you pick related patch to your branch? Anyway I've already
provided interesting test result, I can volunteer to test more if
required, but it would be nice to have the branch build out of box ;-)

-- 
Regards,
Qian Hong

-
http://www.winehq.org

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 01:22 PM, Qian Hong wrote:
> On Tue, Nov 3, 2015 at 9:08 PM, Pedro Alves <palves@redhat.com> wrote:
>> Sorry, these patches need to be submitted to the relevant lists (we can't
>> just pull them, due to copyright assignment requirements), along with
>> rationale for them.  The binutils/ subdir is maintained by the binutils
>> team.  libiberty/ by the GCC folks.  See the top level MAINTAINTERS file
>> for the full mapping.
> 
> Understand, thanks.
> 
>> BTW, this patch should fix the error in the pastebin above:
> 
>> https://sourceware.org/ml/gdb-patches/2015-10/msg00733.html
> 
> Hmm, could you pick related patch to your branch? Anyway I've already
> provided interesting test result, I can volunteer to test more if
> required, but it would be nice to have the branch build out of box ;-)

I had simply forgotten that.  :-)  I've pushed that patch on
the branch now.

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/03/2015 12:56 PM, Qian Hong wrote:

> I tried `make all-gdb` instead of `make all`, now new error found:
> http://pastebin.com/rM7V7msA

BTW, this patch should fix the error in the pastebin above:

 https://sourceware.org/ml/gdb-patches/2015-10/msg00733.html

Thanks,
Pedro Alves

Re: [PATCH 00/11] C++/MinGW patches

[Simon Marchi]

On 15-11-02 02:35 PM, Pedro Alves wrote:
> I tried cross building gdb for --host=x86_64-w64-mingw32 using Fedora
> 20's g++ (gcc version 4.8.4 20141219 (Fedora MinGW 4.8.4-1.fc20)).
> 
> This fixes all issues I found which aren't already sorted in the C++
> branch and/or have fixes already posted.
> 
> This is only build-tested.
> 
> Pedro Alves (11):
>   [C++/mingw] ser-mingw.c casts
>   [C++/mingw] Misc alloca casts
>   [C++/mingw] gdb-dlfcn.c casts
>   [C++/mingw] windows-nat.c casts
>   [C++/mingw] gdbserver casts
>   [C++/mingw] ser-tcp.c casts
>   [C++/mingw] Define __STDC_CONSTANT_MACROS / __STDC_LIMIT_MACROS for
>     stdint.h
>   [C++/mingw] Simplify first chance exception handling
>   [C++/mingw] handle_output_debug_string
>   [C++/mingw] Fix windows-nat.c::xlate
>   [C++/mingw] gdbserver: gdb/host signal mixup
> 
>  gdb/common/common-defs.h       |  16 +++++
>  gdb/exec.c                     |   2 +-
>  gdb/gdb-dlfcn.c                |   4 +-
>  gdb/gdbserver/win32-i386-low.c |   5 +-
>  gdb/gdbserver/win32-low.c      |  38 ++++++------
>  gdb/ser-mingw.c                |  51 ++++++++--------
>  gdb/ser-tcp.c                  |  19 ++++--
>  gdb/symfile.c                  |   2 +-
>  gdb/utils.c                    |   4 +-
>  gdb/windows-nat.c              | 129 ++++++++++++++++++++++-------------------
>  10 files changed, 151 insertions(+), 119 deletions(-)

This looks good to me.

Re: [PATCH 00/11] C++/MinGW patches

[Pedro Alves]

On 11/02/2015 09:04 PM, Simon Marchi wrote:

> This looks good to me.

Thanks Simon.  I've now pushed this series in.

-- 
Pedro Alves