From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic307-54.consmr.mail.ir2.yahoo.com (sonic307-54.consmr.mail.ir2.yahoo.com [87.248.110.31]) by sourceware.org (Postfix) with ESMTPS id 661D33865C2A for ; Fri, 18 Sep 2020 14:27:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 661D33865C2A X-YMail-OSG: zxTR9uMVM1nz6fjw3CjxO3Qf9JwdB3tIqKqMsaI6YcAPs.9rx.MP3eM_nyELrxv vhmw03c4GO0zp5qtA3zvXSTL1pYzEzwZDOArLYWCw69E2EZhE5NvN3JjndnIqwh2SeDbHf1bII5q owV1C4we0LKeUZ2NmAmhCQtE6pFlwmldr0XsEEPpkLi6FqSoS7XkEZirfzliJ01XK6IWl6gVxJDj k9kNTjS2EnIj12w9Wqx_h_1jTmGUCxrNEJj0WeVIZs0IgPJ8D3M0dQweNNZktcXmI74x19SgdhBB Et0.KMMJ7kJGU.Og3Rkj7MvS8O_foCrl9nPopKolL.WlQcBsG_Rc8ooS7qr1shSIhQTfqxBU7T59 rpc7.dnuc2k35LAwaEyFK9nqB2M8Lo2g7m6hmoXR70.WGjUfF5UKAKErG1iRysK2TGoFWh7t1TYK Wg50u2m3_OH_MZsrFpMh5t_FOI.g6i3_W3Ruqj529GiKLaoZeK1x8YLFCpITUHwsn1vwSjAYjS86 _sGK_Z7fLK2AyDAD62jXW5jPHBT_CA2svtIAb4lfcSRwyIWR0qQ3nOnR0H9gPshRYFGdjuUcnkK4 qt6NAHxhl0qcR7WtL.aNnDYYy3.EZoGaUwa1Z8COmZwZCYo14mCjRPYtD.Xg31Hr7Msib_nI.zYQ ..q1RX2HCtD9RU4IxX5mIYZ2WtTy0.xX0CkxTPNJdosztyb_yem1a6Bj4tohmIhPfRe0p7kJy5iN qoCt8ZYYg.RvEYl9vCqWI0oRUn9icytP2ZTbvjkO_UXmGLuMMEEvJZNZ82xoEutwEQl1.V_aHZoC w90sjlZauf5.SSe1cHfY1.1DyMBFyrE4AY.yMnLGpmy9PPChho7zjPbdWDHMaMtEsS1zy0RbOnil _q1mgJPJuIMryg82Dtfpv3QNWuMujHvWcxUapWvGHmYwAgmkUTUAdYqy.4YbDJlohroCsFfmg4aQ KDbkGuaHIacThKGIn8aRn0R6KerfNHB1qGvhmqjS5xpLGHWLMNjCHaTc4yTxkxhDtGrT4CAhjrpy spEt3_FkaWlG3AFWjw.hswFxJnn.fE_sxdfNWdxmRDxP7rqDMJ_IHeyId0YuQ46fwE9P.PencDHG 91OMJkbPmzu.PdHvIo2g0Iyz0g_UUcYt5mleaheMzyZes4VTQ2JtYgphhGivvcomTrFMc311FEej GQhPASiZJ2Ioy7hoFZVgHPO_xHlGVTwEevZPLCHh4AnzwL4GgISVnFyoc_o8vEdcj7LDXu4N4mUZ U78Y7Xeg0FlnjpTiPIbAlaTNyDeIzgWBPULy2lKTnOKUZ3GN0r3KghZtkZ0SuflQkfbnfnu0Qdn8 aGmp7zxmIEBEx9Ed6hTD3gfRNp.edC6GJVgcQbzy16be9H.NG9tg8b.0vrEGUyw2CM1y2MlUda5E P8NK.5DDU_Y62MYhrGzBf_q3sNt6Rsd5a0fHNts8Q_FH8CX_NdBnR2qKgKH9EFOECUnkn_A5NmFh .CTSETwk- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Fri, 18 Sep 2020 14:27:21 +0000 Date: Fri, 18 Sep 2020 14:27:20 +0000 (UTC) From: Hannes Domani To: Hannes Domani via Gdb-patches , Tom Tromey , Simon Marchi Message-ID: <725154490.1784012.1600439240290@mail.yahoo.com> In-Reply-To: <334596674.1355343.1600376198632@mail.yahoo.com> References: <20200917180337.1984-1-ssbssa.ref@yahoo.de> <20200917180337.1984-1-ssbssa@yahoo.de> <871rj06tub.fsf@tromey.com> <334596674.1355343.1600376198632@mail.yahoo.com> 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=-3.4 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 14:27:23 -0000 Am Donnerstag, 17. September 2020, 22:56:45 MESZ hat Hannes Domani via Gdb= -patches Folgendes geschrieben: > Am Donnerstag, 17. September 2020, 22:18:01 MESZ hat Tom Tromey Folgendes geschrieben: > > > >>>>> "Hannes" =3D=3D Hannes Domani via Gdb-patches writes: > > > > Hannes> 2020-09-17=C2=A0 Hannes Domani=C2=A0 > > > > Hannes>=C2=A0=C2=A0=C2=A0=C2=A0 * windows-nat.c (ctrl_c_handler): Use 3= 2bit DbgUiRemoteBreakin > > Hannes>=C2=A0=C2=A0=C2=A0=C2=A0 for WOW64 processes. > > > > Does gdbserver need this treatment as well? > > If so maybe this code can be shared. > > I thought so, but I just tried it and it works without it. > > The reason seems to be that gdbserver first calls GenerateConsoleCtrlEven= t(), > and only when that fails falls back to DebugBreakProcess(). > > When I tried to do the same in gdb just now, it didn't work. > Weird, I will have to investigate this some more. 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 a= ll. 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 faked_breakpoint =3D 1; =C2=A0=C2=A0 memset (¤t_event, 0, sizeof (current_event)); +=C2=A0 current_event.dwProcessId =3D current_process_id; =C2=A0=C2=A0 current_event.dwThreadId =3D main_thread_id; =C2=A0=C2=A0 current_event.dwDebugEventCode =3D EXCEPTION_DEBUG_EVENT; =C2=A0=C2=A0 current_event.u.Exception.ExceptionRecord.ExceptionCode But this didn't work either, I think it's because gdb checks if the current instruction is int3, and continues if not. I'm wondering why this last resort was added, was this done for pre-XP wher= e DebugBreakProcess() didn't exist? So right now ctrl-c doesn't really work that well with gdbserver, and not at all when debugging a program without console (WOW64 or not doesn't matte= r). And the WOW64 fix for DbgUiRemoteBreakin() probably can't be used in gdbserver, because find_minimal_symbol_address() is not available. 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 *ourstatus,= bool debug_exceptions) =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 if (ignore_first_breakpoint) =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 on startup, first a BREAK= POINT for the 64bit ntdll.dll, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then a WX86_BREAKPOINT fo= r the 32bit ntdll.dll. =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Here we only care about t= he 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 ourstatus->kin= d =3D TARGET_WAITKIND_SPURIOUS; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ignore_first_breakpo= int =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=C2=A0=C2=A0 DEBUG_EXCEPTION_SIMPLE ("= EXCEPTION_BREAKPOINT"); +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rec->ExceptionCode =3D DB= G_CONTROL_C; +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ourstatus->value.sig =3D = GDB_SIGNAL_INT; +=C2=A0=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 } =C2=A0#endif =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* FALLTHROUGH */ =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 stops the target process in any case. So far this seems to work fine for both gdb and gdbserver. Hannes