From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62832 invoked by alias); 4 Mar 2020 20:07:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 62824 invoked by uid 89); 4 Mar 2020 20:07:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Mar 2020 20:07:53 +0000 Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (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 6AABB1E4B2; Wed, 4 Mar 2020 15:07:51 -0500 (EST) Subject: Re: [PATCH v3] Implement debugging of WOW64 processes To: Hannes Domani , Gdb-patches References: <20200304191632.14947-1-ssbssa.ref@yahoo.de> <20200304191632.14947-1-ssbssa@yahoo.de> <711a3001-da27-4400-5d11-93ed14e503f2@simark.ca> <667267301.7060481.1583351203448@mail.yahoo.com> From: Simon Marchi Message-ID: <8066975e-aabe-7c46-1ba2-1ad30f3c935e@simark.ca> Date: Wed, 04 Mar 2020 20:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <667267301.7060481.1583351203448@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2020-03/txt/msg00099.txt On 2020-03-04 2:46 p.m., Hannes Domani via gdb-patches wrote: > Am Mittwoch, 4. März 2020, 20:32:52 MEZ hat Simon Marchi Folgendes geschrieben: > >> On 2020-03-04 2:16 p.m., Hannes Domani via gdb-patches wrote: >>> @@ -99,7 +99,5 @@ void _initialize_amd64_windows_nat (); >>>   void >>>   _initialize_amd64_windows_nat () >>>   { >>> -  windows_set_context_register_offsets (mappings); >>> -  windows_set_segment_register_p (amd64_windows_segment_register_p); >>>     x86_set_debug_register_length (8); >>>   } >> >> Does x86_set_debug_register_length need to be adjusted based on the type of the >> process?  With the current code, it will be set to 8 even if debugging a WOW64 >> process, is that what we want? > > I don't really know what this is for, but I haven't had any problem so far like this. It looks like it should be set to the size of the DR registers of the debugee. When debugging a standard x86-64 process, those registers are 8 bytes long (DWORD64): https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-context But when debugging a WOW64 process, they appear to be 4 bytes long (DWORD): https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-wow64_context So it looks wrong that there is a single global value for this. If you were debugging one 64 bits and one 32 bits process, I guess you would want one value per inferior. If you search for uses of the x86_dr_low.debug_register_length field (most of them are hidden behind macros), you'll see that this is used for setting watchpoints properly. So if something should break, it would be in that area. I'm fine with leaving this as-is in the current patch, since it would require a good refactor of x86-nat/x86-dregs to make that value per inferior (if that's even the right thing to do). Note that the x86-linux-nat target also sets this value just once in its _initialize: x86_set_debug_register_length (sizeof (void *)); I don't know what happens then when debugging a 32 bits process from a 64 bits GDB (or vice versa) on x86/Linux. Anyway, this version of the patch LGTM, thanks. Simon