From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id DADFD385DC23 for ; Wed, 15 Apr 2020 15:27:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DADFD385DC23 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 4D51C1E5F9; Wed, 15 Apr 2020 11:27:36 -0400 (EDT) Subject: Re: [PATCH v3 21/29] Share handle_exception To: Tom Tromey , gdb-patches@sourceware.org References: <20200313190855.28662-1-tromey@adacore.com> <20200313190855.28662-22-tromey@adacore.com> From: Simon Marchi Message-ID: <33cddd77-b9c5-dfaa-78cb-2812016b07fd@simark.ca> Date: Wed, 15 Apr 2020 11:27:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200313190855.28662-22-tromey@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 15:27:38 -0000 On 2020-03-13 3:08 p.m., Tom Tromey wrote: > Both gdb and gdbserver have a "handle_exception" function, the bulk of > which is shared between the two implementations. This patch arranges > for the entire thing to be moved into nat/windows-nat.c, with the > differences handled by callbacks. This patch introduces one more > callback to make this possible. > > gdb/ChangeLog > 2020-03-13 Tom Tromey > > * windows-nat.c (MS_VC_EXCEPTION): Move to nat/windows-nat.c. > (handle_exception_result): Move to nat/windows-nat.h. > (DEBUG_EXCEPTION_SIMPLE): Remove. > (windows_nat::handle_ms_vc_exception): New function. > (handle_exception): Move to nat/windows-nat.c. > (get_windows_debug_event): Update. > (STATUS_WX86_BREAKPOINT, STATUS_WX86_SINGLE_STEP): Move to > nat/windows-nat.c. > * nat/windows-nat.h (handle_ms_vc_exception): Declare. > (handle_exception_result): Move from windows-nat.c. > (handle_exception): Declare. > * nat/windows-nat.c (MS_VC_EXCEPTION, handle_exception) > (STATUS_WX86_SINGLE_STEP, STATUS_WX86_BREAKPOINT): Move from > windows-nat.c. This patch introduced some GDB-specific calls in nat/windows-nat.c. That file is built by gdbserver, so it breaks that build. This is when building on Cygwin: CXX nat/windows-nat.o /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/windows-nat.c: In function ‘windows_nat::handle_exception_result windows_nat::handle_exception(target_waitstatus*, bool)’: /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/windows-nat.c:200:8: error: ‘cygwin_exceptions’ was not declared in this scope 200 | if ((!cygwin_exceptions && (addr >= cygwin_load_start | ^~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/windows-nat.c:200:38: error: ‘cygwin_load_start’ was not declared in this scope 200 | if ((!cygwin_exceptions && (addr >= cygwin_load_start | ^~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/windows-nat.c:201:19: error: ‘cygwin_load_end’ was not declared in this scope 201 | && addr < cygwin_load_end)) | ^~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/windows-nat.c:202:10: error: ‘find_pc_partial_function’ was not declared in this scope 202 | || (find_pc_partial_function (addr, &fn, NULL, NULL) | ^~~~~~~~~~~~~~~~~~~~~~~~ Simon