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 A91EA3861012 for ; Thu, 17 Sep 2020 20:00:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A91EA3861012 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] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 40FDF1E50D; Thu, 17 Sep 2020 16:00:28 -0400 (EDT) Subject: Re: [PATCH] Fix ctrl-c when debugging WOW64 processes To: Hannes Domani , gdb-patches@sourceware.org References: <20200917180337.1984-1-ssbssa.ref@yahoo.de> <20200917180337.1984-1-ssbssa@yahoo.de> From: Simon Marchi Message-ID: <0c8dc56c-22cd-be59-3fdb-bae6878ea331@simark.ca> Date: Thu, 17 Sep 2020 16:00:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200917180337.1984-1-ssbssa@yahoo.de> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, 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: Thu, 17 Sep 2020 20:00:29 -0000 On 2020-09-17 2:03 p.m., Hannes Domani via Gdb-patches wrote: > DebugBreakProcess starts a new thread in the target process with the > entry point DbgUiRemoteBreakin, where an int3 triggers a breakpoint > exception for gdb. > > But this uses DbgUiRemoteBreakin of the 64bit ntdll.dll even for > WOW64 processes. > It stops in 64bit code, Wow64GetThreadContext reports a wrong pc without > the int3, and gdb lets the target process continue. > > So this uses DbgUiRemoteBreakin of the 32bit ntdll.dll as the thread > entry point for WOW64 processes instead. Interesting. Is there any reference somewhere that explains that things must be done this way when a 64 bit process is debugging a 32 bit process? In any case, the patch is OK, with the formatting nits below fixed. > @@ -1522,9 +1524,36 @@ ctrl_c_handler (DWORD event_type) > if (!new_console && !attach_flag) > return TRUE; > > - if (!DebugBreakProcess (current_process_handle)) > - warning (_("Could not interrupt program. " > - "Press Ctrl-c in the program console.")); > +#ifdef __x86_64__ > + if (wow64_process) > + { > + /* Call DbgUiRemoteBreakin of the 32bit ntdll.dll in the target process. > + DebugBreakProcess would call the one of the 64bit ntdll.dll, which > + can't be correctly handled by gdb. */ > + if (!wow64_dbgbreak) wow64_dbgbreak == nullptr > + { > + CORE_ADDR addr; > + if (!find_minimal_symbol_address ("ntdll!DbgUiRemoteBreakin", > + &addr, 0)) > + wow64_dbgbreak = (void *) addr; > + } > + > + if (wow64_dbgbreak) wow64_dbgbreak != nullptr Simon