From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic311-31.consmr.mail.ir2.yahoo.com (sonic311-31.consmr.mail.ir2.yahoo.com [77.238.176.163]) by sourceware.org (Postfix) with ESMTPS id 156F03857C43 for ; Fri, 18 Sep 2020 16:09:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 156F03857C43 X-YMail-OSG: MqYJQmwVM1kW2Rnx.V43xS47YCJWELgv.O5KtfWIjAkMva9jPWsV8SC8T0_jXRl 1ofOwkgrOhhJqkd6OLdPFXUsMkD3DI6zvfiduJL2aI4_NeZn5uaVZRCWqM8Jz0oAG2g_dmS_YGuq 5Fc8vzkatxkVCPN9j7Uhcuyj10NJMaOVqjS9ROBc9nnNJ5TUroYCXw_YHoiSGDdLnOyW484kWCZ3 RiJilqLcZdH30N_byMS3106_58t.Ev2z1v4CmnWSUi6O4X6CdnFvOAVgL4Yam2BhsZ516V_1Ldsw _8To6.H_AnNuqK3BVOV7nG4vvAGkMK2tO_Sm.LfCKsV8C4kBEZKwZl3Zk8TLfgqj_W40R.tUEHOT ZzMNwr1LuKfOLQg5OHugdrawBPrxkpfxCCatH2OWolw92mTp.FttZXD2zhDjfsVe7Q6gyXPzMx1h SZn6K4oBMPEwCMdzcKPYOpV0jSL8hJRA.ZGJkyYAukXkeCYvf.RfK2QR9htJihEhPmUK7EcCGXQj WjSBrMa5JJiJ9ZVkIVRN1uo.8UVyA1.ZC6DXyTNoVYhPQAA24GuS.ABJErZfneUk21Uk369v4TKO OdTABmnwWygE1OjcBTOgvs.fXDQBBn9ZuCmtSa9faY8VBQDUlHDY1OvgxvgOEIo6YznYWiqzA_71 MVoyYKRq.fRnNUhpdHEsxXqvObi7XMb8WC2sJROZfSZn3rweV54hKAyTuz6uTR8XYhsYMKJRB1OA orxXWyjMagZtfCKCITVTQhxLR6_H4ex1lAtse9XLm3fSTveBXxlRHzDzsR6NwvBwJU302csi0vZ. yNHZj5KCp51QHt44g_Oqb6iY.Kz7i0FCCwS07OkMxVjcuKMSdpxoTNBJz9izFzvAkoaB7jRzlvKD bbx4A6QHq5rz8daC_D22ir_4H1jf16RCH3vU2QWvuqBq2NkCn492PU6mpk.MhWKmXWiegAlw0Nao O3l6uzPSFj6627NhjEXBLCbNduouW21F2IWo5m9HXxONoV4dm1Qy0fcYU8SgrjHg08G3hWh2p4rg YeiBQ3x1uAJNrAavbkbuqxwTODd1aQ2hUYDKVvtUrax6wjmjr6rGOCO27LW7qUcudtjPs8ZHPger JMoIdljlR_ExAgJ_4LDP8R6xdMs_u.0AsoA1MYA8OA_0nAQHnoKlfs_YQ1hbhXId9IOfoVOZ1G9P MKN0Ur_NxGYAGyOktdog7Q10edhwx1mKcSi8L_TrSi2p_5m8u.le32Ivt_9ceDkxvYSp6Fc6JSwG b5evAWl6WTeBlE1lBzVgUYFrZdq1IBajWzbVr55Kuk1ercDemzgYpYUeyzAinQ.CS3KiUcV94U8H z9GajNO.oucc__enw9xGGsM16xVkJSifZDxtdBQu1CWrmYJ4rablhW1zhSUna6c6cm9pM7LKqmJ0 hZM7ejlFZ.I2ApmmGf7nUZEw2SgceOvpb5ucRV9dA5X_0raAAwHdl7LkFJOQhkk2UlhCKGXPmiVB YmJWtn4dTPeOTUw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ir2.yahoo.com with HTTP; Fri, 18 Sep 2020 16:09:13 +0000 Date: Fri, 18 Sep 2020 16:09:10 +0000 (UTC) From: Hannes Domani To: Hannes Domani via Gdb-patches , Tom Tromey , Simon Marchi Message-ID: <1686166314.1857568.1600445350521@mail.yahoo.com> In-Reply-To: <4f1a700a-e704-56f6-02fd-f0d9579102e3@simark.ca> References: <20200917180337.1984-1-ssbssa.ref@yahoo.de> <20200917180337.1984-1-ssbssa@yahoo.de> <871rj06tub.fsf@tromey.com> <334596674.1355343.1600376198632@mail.yahoo.com> <725154490.1784012.1600439240290@mail.yahoo.com> <4f1a700a-e704-56f6-02fd-f0d9579102e3@simark.ca> Subject: Re: [PATCH] Fix ctrl-c when debugging WOW64 processes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.16583 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0 X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, 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: Fri, 18 Sep 2020 16:09:16 -0000 Am Freitag, 18. September 2020, 17:48:58 MESZ hat Simon Marchi Folgendes geschrieben: > On 2020-09-18 10:27 a.m., Hannes Domani wrote: > > I did some experiments. > > > > Seems like GenerateConsoleCtrlEvent() only works if the target process = was > > created without CREATE_NEW_CONSOLE. > > And what's worse, it seems to always return TRUE, so it never reaches > > DebugBreakProcess(), even if the target process doesn't have a console = at all. > > > > I also tried the "last resort", with soft_interrupt_requested=3D1, but = this > > immediatly crashed gdbserver. > > > > I fixed this crash with: > > > > --- a/gdbserver/win32-low.cc > > +++ b/gdbserver/win32-low.cc > > @@ -1339,6 +1335,7 @@ fake_breakpoint_event (void) > >=C2=A0=C2=A0=C2=A0 faked_breakpoint =3D 1; > > > >=C2=A0=C2=A0=C2=A0 memset (¤t_event, 0, sizeof (current_event)); > > +=C2=A0 current_event.dwProcessId =3D current_process_id; > >=C2=A0=C2=A0=C2=A0 current_event.dwThreadId =3D main_thread_id; > >=C2=A0=C2=A0=C2=A0 current_event.dwDebugEventCode =3D EXCEPTION_DEBUG_EV= ENT; > >=C2=A0=C2=A0=C2=A0 current_event.u.Exception.ExceptionRecord.ExceptionCo= de > > > > But this didn't work either, I think it's because gdb checks if the cur= rent > > instruction is int3, and continues if not. > > > > I'm wondering why this last resort was added, was this done for pre-XP = where > > DebugBreakProcess() didn't exist? > > I digged a little bit.=C2=A0 It was introduced by this commit by a young > Pedro :) > >=C2=A0=C2=A0 https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dcommit;h= =3D4d5d1aaa19ea > > The corresponding mailing list post is: > >=C2=A0=C2=A0 https://sourceware.org/legacy-ml/gdb-patches/2007-11/msg00217= .html > > It doesn't explain the rationale though, it just implicitly refers to a > previous thread.=C2=A0 It's probably this one, which gives a bit more > context: > >=C2=A0=C2=A0 https://sourceware.org/legacy-ml/gdb-patches/2007-11/msg00035= .html > > From what I understand, this was for WinCE, which lacked > GenerateConsoleCtrlEvent and DebugBreakProcess.=C2=A0 Since we removed > support for WinCE, I think that code could very well be GC'ed. > > > > > So right now ctrl-c doesn't really work that well with gdbserver, and n= ot > > at all when debugging a program without console (WOW64 or not doesn't m= atter). > > > > > > And the WOW64 fix for DbgUiRemoteBreakin() probably can't be used in > > gdbserver, because find_minimal_symbol_address() is not available. > > Using the qSymbol packet, there is a window during which GDBserver can > as GDB to look up minimal symbol values.=C2=A0 On the GDBserver side, thi= s is > done through process_stratum_target::look_up_symbols, you would just > need to implement it for win32_process_target. OK, I will look into this (even though we maybe won't need it). > > Meanwhile I came up with a possible alternative for DbgUiRemoteBreakin(= ): > > > > --- a/gdb/nat/windows-nat.c > > +++ b/gdb/nat/windows-nat.c > > @@ -240,6 +241,13 @@ handle_exception (struct target_waitstatus *oursta= tus, bool debug_exceptions) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case EXCEPTION_BREAKPOINT: > >=C2=A0 #ifdef __x86_64__ > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (ignore_first_breakpoint) > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* For WOW64 processes, there= are always 2 breakpoint exceptions > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 on startup, first= a BREAKPOINT for the 64bit ntdll.dll, > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then a WX86_BREAK= POINT for the 32bit ntdll.dll. > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Here we only care= about the WX86_BREAKPOINT's.=C2=A0 */ > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ourst= atus->kind =3D TARGET_WAITKIND_SPURIOUS; > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ignore_first_brea= kpoint =3D false; > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else if (wow64_process) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DEBUG_EXCEPTION_SIMPLE ("EX= CEPTION_BREAKPOINT"); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rec->ExceptionCode =3D DBG_= CONTROL_C; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ourstatus->value.sig =3D GD= B_SIGNAL_INT; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > >=C2=A0 #endif > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* FALLTHROUGH */ > >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case STATUS_WX86_BREAKPOINT: > > > > This transforms the (64bit) breakpoint from DebugBreakProcess() into > > SIGINT, then the check for the int3 instruction is not done, and gdb st= ops > > the target process in any case. > > > That sounds simple (which is good).=C2=A0 Would this replace completely > spawning the remote thread (which you added in the previous patch)? Yes, this would replace the remote thread. Hannes