From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110353 invoked by alias); 4 Mar 2020 20:18:49 -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 110345 invoked by uid 89); 4 Mar 2020 20:18:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*x:5.0, H*x:Windows X-HELO: sonic307-54.consmr.mail.ir2.yahoo.com Received: from sonic307-54.consmr.mail.ir2.yahoo.com (HELO sonic307-54.consmr.mail.ir2.yahoo.com) (87.248.110.31) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Mar 2020 20:18:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1583353124; bh=TqvTjcV5hsFyqeTNKPb8WW/LvQqBZZWqdC5uzoaLLCc=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=rFmxGSWqw1jVBJc9X1L8AkEO+el6osuDjU8kLpDmx0GwyZHniwklJga17igDMhtY/f9kK0H9bkN64zmw2USrN/MWnN9aI7Dy18LKyX9az2zWA3Bc7Kp7IpkqFdB6tZ37NAGc35Da0kthvPcB8s/LnqzV86kh1sDPjaGnATRbUQFifioCowZPSvfIu0+Q3ujlurScfWCTMZSdHQGqrGek6OuGtfK6pzALhM+GydzKyusjwvWKTF1LR6Ynd08paq695HH82nywotidEMlPGz5cw8++MfWuz866lWkNYBWtGIPsDe3PjJhiIS4cseHa893k5on3np0r0qctaF2pRX9n3g== Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Wed, 4 Mar 2020 20:18:44 +0000 Date: Wed, 04 Mar 2020 20:18:00 -0000 From: "Hannes Domani via gdb-patches" Reply-To: Hannes Domani To: Gdb-patches Message-ID: <1757969531.7018208.1583353115677@mail.yahoo.com> In-Reply-To: <8066975e-aabe-7c46-1ba2-1ad30f3c935e@simark.ca> 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> <8066975e-aabe-7c46-1ba2-1ad30f3c935e@simark.ca> Subject: Re: [PATCH v3] Implement debugging of WOW64 processes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00100.txt Am Mittwoch, 4. M=C3=A4rz 2020, 21:07:53 MEZ hat Simon Marchi Folgendes geschrieben: > On 2020-03-04 2:46 p.m., Hannes Domani via gdb-patches wrote: > >=C2=A0 Am Mittwoch, 4. M=C3=A4rz 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 (); > >>>=C2=A0=C2=A0 void > >>>=C2=A0=C2=A0 _initialize_amd64_windows_nat () > >>>=C2=A0=C2=A0 { > >>> -=C2=A0 windows_set_context_register_offsets (mappings); > >>> -=C2=A0 windows_set_segment_register_p (amd64_windows_segment_registe= r_p); > >>>=C2=A0=C2=A0=C2=A0=C2=A0 x86_set_debug_register_length (8); > >>>=C2=A0=C2=A0 } > >> > >> Does x86_set_debug_register_length need to be adjusted based on the ty= pe of the > >> process?=C2=A0 With the current code, it will be set to 8 even if debu= gging 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 deb= ugee. > > When debugging a standard x86-64 process, those registers are 8 bytes lon= g (DWORD64): > >=C2=A0=C2=A0 https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-w= innt-context > > But when debugging a WOW64 process, they appear to be 4 bytes long (DWORD= ): > >=C2=A0=C2=A0 https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-w= innt-wow64_context > > So it looks wrong that there is a single global value for this.=C2=A0 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 (mos= t of them > are hidden behind macros), you'll see that this is used for setting watch= points > properly.=C2=A0 So if something should break, it would be in that area. I tested watchpoints with WOW64 processes as well, didn't have any problems. > I'm fine with leaving this as-is in the current patch, since it would req= uire 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: > >=C2=A0=C2=A0 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. Pushed, thanks Regards Hannes Domani