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: linkBe 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).