public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Tom Tromey <tromey@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] Fix Cygwin gdb build
Date: Thu, 16 Apr 2020 13:25:19 +0000 (GMT)	[thread overview]
Message-ID: <20200416132519.09F71385DC1E@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a010605fef0eba73c564c3dd22e0a6ecbc26b10e

commit a010605fef0eba73c564c3dd22e0a6ecbc26b10e
Author: Tom Tromey <tromey@adacore.com>
Date:   Thu Apr 16 07:24:57 2020 -0600

    Fix Cygwin gdb build
    
    Simon pointed out that the windows-nat sharing series broke the Cygwin
    build.  This patch fixes the problem, by moving the Cygwin-specific
    code to a new handler function.  This approach is taken because this
    code calls find_pc_partial_function, which isn't available in
    gdbserver.
    
    gdb/ChangeLog
    2020-04-16  Tom Tromey  <tromey@adacore.com>
    
            * windows-nat.c (windows_nat::handle_access_violation): New
            function.
            * nat/windows-nat.h (handle_access_violation): Declare.
            * nat/windows-nat.c (handle_exception): Move Cygwin code to
            windows-nat.c.  Call handle_access_violation.
    
    gdbserver/ChangeLog
    2020-04-16  Tom Tromey  <tromey@adacore.com>
    
            * win32-low.cc (windows_nat::handle_access_violation): New
            function.

Diff:
---
 gdb/ChangeLog          |  8 ++++++++
 gdb/nat/windows-nat.c  | 22 ++--------------------
 gdb/nat/windows-nat.h  |  7 +++++++
 gdb/windows-nat.c      | 25 +++++++++++++++++++++++++
 gdbserver/ChangeLog    |  5 +++++
 gdbserver/win32-low.cc |  8 ++++++++
 6 files changed, 55 insertions(+), 20 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index b019ca9b461..7ba862edd34 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,11 @@
+2020-04-16  Tom Tromey  <tromey@adacore.com>
+
+	* windows-nat.c (windows_nat::handle_access_violation): New
+	function.
+	* nat/windows-nat.h (handle_access_violation): Declare.
+	* nat/windows-nat.c (handle_exception): Move Cygwin code to
+	windows-nat.c.  Call handle_access_violation.
+
 2020-04-16  Tom de Vries  <tdevries@suse.de>
 
 	PR symtab/25791
diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
index cd7c1d177c6..8c2092a51d7 100644
--- a/gdb/nat/windows-nat.c
+++ b/gdb/nat/windows-nat.c
@@ -184,26 +184,8 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
     case EXCEPTION_ACCESS_VIOLATION:
       DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_ACCESS_VIOLATION");
       ourstatus->value.sig = GDB_SIGNAL_SEGV;
-#ifdef __CYGWIN__
-      {
-	/* See if the access violation happened within the cygwin DLL
-	   itself.  Cygwin uses a kind of exception handling to deal
-	   with passed-in invalid addresses.  gdb should not treat
-	   these as real SEGVs since they will be silently handled by
-	   cygwin.  A real SEGV will (theoretically) be caught by
-	   cygwin later in the process and will be sent as a
-	   cygwin-specific-signal.  So, ignore SEGVs if they show up
-	   within the text segment of the DLL itself.  */
-	const char *fn;
-	CORE_ADDR addr = (CORE_ADDR) (uintptr_t) rec->ExceptionAddress;
-
-	if ((!cygwin_exceptions && (addr >= cygwin_load_start
-				    && addr < cygwin_load_end))
-	    || (find_pc_partial_function (addr, &fn, NULL, NULL)
-		&& startswith (fn, "KERNEL32!IsBad")))
-	  return HANDLE_EXCEPTION_UNHANDLED;
-      }
-#endif
+      if (handle_access_violation (rec))
+	return HANDLE_EXCEPTION_UNHANDLED;
       break;
     case STATUS_STACK_OVERFLOW:
       DEBUG_EXCEPTION_SIMPLE ("STATUS_STACK_OVERFLOW");
diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h
index aea1519672d..8d0fa9bd216 100644
--- a/gdb/nat/windows-nat.h
+++ b/gdb/nat/windows-nat.h
@@ -157,6 +157,13 @@ extern void handle_unload_dll ();
 
 extern bool handle_ms_vc_exception (const EXCEPTION_RECORD *rec);
 
+/* When EXCEPTION_ACCESS_VIOLATION is processed, we give the embedding
+   application a chance to change it to be considered "unhandled".
+   This function must be supplied by the embedding application.  If it
+   returns true, then the exception is "unhandled".  */
+
+extern bool handle_access_violation (const EXCEPTION_RECORD *rec);
+
 
 /* Currently executing process */
 extern HANDLE current_process_handle;
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index e82e58ec1f2..b857f82eb89 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1230,6 +1230,31 @@ windows_nat::handle_ms_vc_exception (const EXCEPTION_RECORD *rec)
   return false;
 }
 
+/* See nat/windows-nat.h.  */
+
+bool
+windows_nat::handle_access_violation (const EXCEPTION_RECORD *rec)
+{
+#ifdef __CYGWIN__
+  /* See if the access violation happened within the cygwin DLL
+     itself.  Cygwin uses a kind of exception handling to deal with
+     passed-in invalid addresses.  gdb should not treat these as real
+     SEGVs since they will be silently handled by cygwin.  A real SEGV
+     will (theoretically) be caught by cygwin later in the process and
+     will be sent as a cygwin-specific-signal.  So, ignore SEGVs if
+     they show up within the text segment of the DLL itself.  */
+  const char *fn;
+  CORE_ADDR addr = (CORE_ADDR) (uintptr_t) rec->ExceptionAddress;
+
+  if ((!cygwin_exceptions && (addr >= cygwin_load_start
+			      && addr < cygwin_load_end))
+      || (find_pc_partial_function (addr, &fn, NULL, NULL)
+	  && startswith (fn, "KERNEL32!IsBad")))
+    return true;
+#endif
+  return false;
+}
+
 /* Resume thread specified by ID, or all artificially suspended
    threads, if we are continuing execution.  KILLED non-zero means we
    have killed the inferior, so we should ignore weird errors due to
diff --git a/gdbserver/ChangeLog b/gdbserver/ChangeLog
index 2abe0f1268c..96642e5cf39 100644
--- a/gdbserver/ChangeLog
+++ b/gdbserver/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-16  Tom Tromey  <tromey@adacore.com>
+
+	* win32-low.cc (windows_nat::handle_access_violation): New
+	function.
+
 2020-04-15  Simon Marchi  <simon.marchi@polymtl.ca>
 
 	* win32-low.cc (get_child_debug_event): Fix format string warning.
diff --git a/gdbserver/win32-low.cc b/gdbserver/win32-low.cc
index 75305a4cfab..5a6f0df39f5 100644
--- a/gdbserver/win32-low.cc
+++ b/gdbserver/win32-low.cc
@@ -1198,6 +1198,14 @@ windows_nat::handle_ms_vc_exception (const EXCEPTION_RECORD *rec)
   return false;
 }
 
+/* See nat/windows-nat.h.  */
+
+bool
+windows_nat::handle_access_violation (const EXCEPTION_RECORD *rec)
+{
+  return false;
+}
+
 /* A helper function that will, if needed, set
    'stopped_at_software_breakpoint' on the thread and adjust the
    PC.  */


                 reply	other threads:[~2020-04-16 13:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200416132519.09F71385DC1E@sourceware.org \
    --to=tromey@sourceware.org \
    --cc=gdb-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).