aboutsummaryrefslogtreecommitdiff
path: root/gdb/windows-nat.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2020-04-16 07:24:57 -0600
committerTom Tromey <tromey@adacore.com>2020-04-16 07:24:57 -0600
commita010605fef0eba73c564c3dd22e0a6ecbc26b10e (patch)
treeab7b331485ab546acfd5141522d5cc0072eb42ac /gdb/windows-nat.c
parentefba5c2319d6c25393e5cce9a2d30bbc0cb53123 (diff)
downloadfsf-binutils-gdb-a010605fef0eba73c564c3dd22e0a6ecbc26b10e.zip
fsf-binutils-gdb-a010605fef0eba73c564c3dd22e0a6ecbc26b10e.tar.gz
fsf-binutils-gdb-a010605fef0eba73c564c3dd22e0a6ecbc26b10e.tar.bz2
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.
Diffstat (limited to 'gdb/windows-nat.c')
-rw-r--r--gdb/windows-nat.c25
1 files changed, 25 insertions, 0 deletions
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index e82e58e..b857f82 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