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 1C0613848E17 for ; Fri, 9 Dec 2022 18:13:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1C0613848E17 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1670609617; bh=YIxoQm0HdmqQvLOyeo1TRXO1yN1F+C69CH13K1ZzPzE=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=IfUUHpp9op0B+45aGj/9rWn+a4kPG0U4d9xka/1tjfC837D30Fq16Qab34c60S8OLvpR2Iiy5KlHq6l/HmhBXptqjXrgh0s6SApjvjOUk3o0oK5SM3cc2H6wBegCNXd1mkq+9vMuwYNk7cc47+2pQVi+ZLw0j9Przu/ljMqH1ZsMdRF6DjHrFsBO4MMm027BWxYVGbLUPBUWI24anhNRJPnFOxT42tcHjEB5OnGIytq/rgvZy+U72mmkN5bbrQVgm7IglbSWnPXBZ3HPAygUKBmRFC4X6kHPq9HQ5Dd7uZ/+sSC+kZGcHPLDu1sqsYOiD349j8KmLXRiz8mavIuA+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670609617; bh=VjeAv9iNusiQQ0caQVjbKgtYFBNs9N0zTMXBxkIZeNv=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ak1pP2VM5JyZZoVxmn0Z8grsB8Ezi8UgY43+MuELvRs/Gpkj4YsdrAkXWROsYUmLjL+DiVzARP+0ovHPPOz5d2XN2NMH2tJJnn7tdfrv9PRwXUCrIX2gNuNDWKXsodU4W9UaXk50HNYWZ0UjsTBJr8IWSi1RQBIY/MSvFfYZRoyFWIsvLTthjhTAqWPrDQzZ2wZkd3Y8llyse2ARMgVW4sL+x0CliNFl+B14B9fVYzuzQlvCoPo+L4NQnYM4HkKL6MuqvuZ28ASqaNu+UN1trUGbYaxiRSGZ6y9G4bvMCBKrmfLy6+iSHJuLRV9402yTpoOQ1nMsoPd6vZROqyQyUg== X-YMail-OSG: tX29jswVM1lN3iq63JpAMqKRLi_UpsQQ1yEloaOshabfQLcXKRrtZAvU2C4o8r9 rirRWvpO2kJzmEN6tB2XPFg7E8zyMOoaZr3lYL0aAyxyucrzc6DJG_y3pO4RegRPFWkSFDeKiDNN Q35xeCuCKrykMiF5MIXrsq_2vgREPch2h0Hxp12XLg8YQDeLU.brGYteDCj1Dk81h6VY9LGQnUsT sNpbfXPgtoa._i2HadMfE2zczyesRa9iyAGUrDP97ZjSb0ifv4yel6xT2VjlZRsLCTpITzH3ngPf DbjGYpFsBH2Wrk0HMofvGghUAthJtNVmMSPd5Fo7mWrHceQ0gu703Qz1.Sd2xNgCk3TUi.6X1B3l ze12rGM1ozY1MSdscnHNDoPuuHDhQ9yEjAdaK8qDIJ55htZ6GCJQ9wxHkmhDDYql6WUR9gCe5vrt RD8w.usvGzdLin5_EuyiMJdvpfmseLdljYMdzZ5BAbwwyhU8YpOd4wZ91dPGtQOO4peacvlvHSnG zw0.keBRoRAVf2RPRwEqsaSNtQ1b5iIT_1at3PMHTQKebIyiyJS2liCBbe_liASBKriFFVJs4Wi_ f0j9Wf3CvSq9cTc2S3n2XCt.o4Ui1gSLFFe7HO.zcdNABViFxRanTc0SIs6ZvRT2pJ_L9bvrxfAY ENYTS.cO7lAn9EYTdj4Md29br67mX.e6eGud1_W4bRughN2XUtrMV8hxo8yXmgJpTnVaEwMTEa2F mdAuCLVNBrdDRmC0G4AIMPLzrMVbjosd.QC6PX_M7OSO1NhYDJ6_6Piqqfe2CSnjEZNeX7KXOnSM CE_NNpbYyxWwo067tLNvJ.aLqF_Pcwf3N2DwXLP_V8Vgd.i0yTfAYUgu3nd5IdH02zZtNaka6kiA ctbVSj1301moqj4s7PbVF2908b6tdxuDXxe0oFMOHVKlRs358n_Ph1vsaX1DLFQfQlB3jT3WSbdj 2DUP0tkUoXhhBplWBB1V3JZT3vTmSt1N5IIxqcOojmFF.n64Eonnnf2o.MppljApzAle83vjxwyf qZVe1MSSUE1MoEko8P5Pgo8L7MVE75e1Y1Lj9xEhyOLgW0.DNmzfg0c1w77UfRV3yeFsaZbcXT4Z 9Uk3iOR2RugD5pPSwU4kRdXDHOZFKuAKJB3OfFSCuztRLvcGGXftUhCD.n.3mnBgNSNpgZVQI2mM yNZPn6YLZzf0SEBeunSR3i.nZtwKRwxjNBGJ87ZkaJs6PVf7hG57xzpOHzWldc4PqJqtu4NjeXv. wadN9GRiINgpP5ghCM0Y67r40FEi1GjG5b8tREP1XqV50gBPUerWLuCrEEMG04xMsW2B0UFqge7f XtnCBxajG2t7eSgfKre_bAE1scjwgnNCtTq037UKsgyYkErjSSMzHgYh66NO8bklpEjgjkSNJPBg xsPvUMRt1fhCq3_R9sRqvvs1_mMt3CBHfGVD2YnlyDB_lUz8HVsR0_iMirJQG1FJuxFY6uEdVbN3 iZK13hrmNAYFshzzT22jnxRjwMwgLyEDhlezmBDV6HnzGWwHTgAiaqkjJcxNTvY7.2bvGGApSwhV Xn1URKZF8_I7xKH9YBdWNoaxZskA_zBapmti8pUU7nJJCFV5cAtQzKhsOdTDURIIHFCzwSxNiu4P 3D0xXFwkLR6k_O4EzEyS9rq42GF_RNxR3jT0Wshzv.oB5hKi3m7LADbVt_k6FbnvQvhGVNaF9qmg Od0xSKTJdkNbQ7kqJJgpOvZnbaQDxsUoElV7hLpHxvrQdeQx0yv0LWbq_f9vDLYTY1EZ3ZpREesa FfQmrbBzaXuDUA.3xktRepqRQSqAWSz0B9eKTuvnsQZdMe3F0BG3LN4HC99aAPzehhKMlOh_L64O MAfQc4REOsHVbAytP.ytZU0nISUfs1umze3VafB4gkvGd9CXMVm37M7Y10VgU0mcqAKxtpu8h5Sg hrtuFtFUisSye7p2Y8EG9VBycQd0Skh_QGOfdrE76LkzzSoR43inUbedmZVIWQuOaVUoMMg38wLL YPVi3PdYAX1t2qatZzsVZEPZlBIWYy8ANlL4zY9DwXlMsWNAoD6Csk4DGOp4CYX5Pne2ikXNTn6S K.Ujp3SFT0Gys3UW6ZVNHIWtv0WCRAKLoymYgjQJqmU6V2HlZuRUa4MSyJg.DBKiYl8UguEEihmc jCyKPurI6Lyggc2n_CpYswyeaYixmwt0PKZiVHw9X_eHAwIu6sOxGtRKgk_gX639LVDSSv6ZBDk2 b.zuua79bYXej.P0SFz4ZdxU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ir2.yahoo.com with HTTP; Fri, 9 Dec 2022 18:13:37 +0000 Date: Fri, 9 Dec 2022 18:13:33 +0000 (UTC) From: Hannes Domani To: Tom Tromey Cc: "gdb-patches@sourceware.org" Message-ID: <127884065.5583846.1670609613440@mail.yahoo.com> In-Reply-To: <87edt8ijd7.fsf@tromey.com> References: <20221205185651.2704492-1-tromey@adacore.com> <20221205185651.2704492-4-tromey@adacore.com> <102195784.4047621.1670433222150@mail.yahoo.com> <87ilikin72.fsf@tromey.com> <1095715284.5500968.1670602756752@mail.yahoo.com> <87edt8ijd7.fsf@tromey.com> Subject: Re: [PATCH 3/3] Fix control-c handling on Windows MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20926 YMailNorrin X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Freitag, 9. Dezember 2022, 18:21:27 MEZ hat Tom Tromey Folgendes geschrieben: > >> If that's the issue then I can write a patch to change sigint_ours to = be > >> a gdb::optional and check it that way. > > Hannes> I should have been more clear about this. > Hannes> I started with 'new-console on', so sharing_input_terminal() retu= rned false, > Hannes> and that's why sigint_ours was not set. > > Hannes> So yes, gdb::optional would probably fix this. > Hannes> I just wonder if this is never an issue on Linux, e.g. if you att= ach, > Hannes> of does signal() maybe ignore NULL-pointer functions? > > Normally SIG_DFL is NULL, but also on Linux I couldn't get this to > trigger inappropriately.=C2=A0 Maybe my theory about what's going on here= is > incorrect. > > Hannes> As far as I could tell, signal() calls SetConsoleCtrlHandler(), p= robably > Hannes> similar to how you handled this. > > Yeah, that was my guess as well, but really we'd want more details. > Like, does calling signal reinstall the SetConsoleCtrlHandler?=C2=A0 If s= o > then why didn't that work for gdb?=C2=A0 But if not then why did we need = to > call SetConsoleCtrlHandler again to tweak the ordering of callbacks? > > Maybe I should go back and try to figure out what else is calling signal > and/or SetConsoleCtrlHandler.=C2=A0 I somewhat suspect Python but I don't > really know. I tried just now to debug signal a bit more, but now I can't reproduce it calling SetConsoleCtrlHandler any more. The more I look, the more confused I get again. > >> I did try 'new-console on' with my (x86-64) build, and that worked fin= e. > >> I can try an x86 build and see if that works any better. > > Hannes> Again, I wasn't clear enough here. > Hannes> The difference is not because of i686 and x86_64, but that the x8= 6_64 build > Hannes> has TUI+python enabled, but my i686 build has not. > > Aha, I see, thanks. > > Hannes> Some TUI startup code would later call install_sigint_handler() a= gain, > Hannes> overriding the SIGINT handler again, and everything is fine. > > Do you know where this happens? Yes, it's because of my extra python TUI windows, which call gdbpy_register_tui_window: #0=C2=A0 install_sigint_handler (fn=3Dfn@entry=3D0x13fde3a50 ) at C:/src/repos/binutils-gdb.git/gdb/mingw-hdep.c:426 #1=C2=A0 0x000000013fde9cdf in install_gdb_sigint_handler (previous=3D0x27b= 88a8) at C:/src/repos/binutils-gdb.git/gdb/extension.c:679 #2=C2=A0 set_active_ext_lang (now_active=3Dnow_active@entry=3D0x1407aee00 <= extension_language_python>) at C:/src/repos/binutils-gdb.git/gdb/extension.= c:736 #3=C2=A0 0x000000013ff4503e in gdbpy_enter::gdbpy_enter (this=3Dthis@entry= =3D0x24c6c0, gdbarch=3Dgdbarch@entry=3D0x0, language=3Dlanguage@entry=3D0x0= ) at C:/src/repos/binutils-gdb.git/gdb/python/python.c:212 #4=C2=A0 0x000000013ff35ac0 in gdbpy_tui_window_maker::gdbpy_tui_window_mak= er (other=3D..., this=3D0x24c6b8) at C:/src/repos/binutils-gdb.git/gdb/pyth= on/py-tui.c:301 #5=C2=A0 gdbpy_register_tui_window (self=3D, args=3D, kw=3D) at C:/src/repos/binutils-gdb.git/gdb/python/= py-tui.c:380 ... And also there is this call later on: #0=C2=A0 install_sigint_handler (fn=3Dfn@entry=3D0x13fde3a50 ) at C:/src/repos/binutils-gdb.git/gdb/mingw-hdep.c:426 #1=C2=A0 0x000000013fde9cdf in install_gdb_sigint_handler (previous=3D0x28a= de48) at C:/src/repos/binutils-gdb.git/gdb/extension.c:679 #2=C2=A0 set_active_ext_lang (now_active=3Dnow_active@entry=3D0x1407aee00 <= extension_language_python>) at C:/src/repos/binutils-gdb.git/gdb/extension.= c:736 #3=C2=A0 0x000000013ff4503e in gdbpy_enter::gdbpy_enter (this=3D0x24f7b0, g= dbarch=3D0x0, language=3D0x0) at C:/src/repos/binutils-gdb.git/gdb/python/p= ython.c:212 #4=C2=A0 0x000000013ff4522a in gdbpy_before_prompt_hook (extlang=3D, current_gdb_prompt=3D0x140be96b0 "(gdb) ") at C:/s= rc/repos/binutils-gdb.git/gdb/python/python.c:1114 #5=C2=A0 0x000000013fde8fc3 in ext_lang_before_prompt (current_gdb_prompt= =3D0x140be96b0 "(gdb) ") at C:/src/repos/binutils-gdb.git/g= db/extension.c:963 #6=C2=A0 0x000000013fde4431 in std::function::operator(= )(char const*) const (__args#0=3D0x140be96b0 "(gdb) ", this= =3D0x4dee28) at c:/msys64/mingw64/x86_64-w64-mingw32/include/c++/11.2.0/bit= s/std_function.h:560 #7=C2=A0 gdb::observers::observable::notify (args#0=3D0x140be9= 6b0 "(gdb) ", this=3D) at c:/src/repos/binut= ils-gdb.git/gdbsupport/observable.h:166 #8=C2=A0 top_level_prompt () at C:/src/repos/binutils-gdb.git/gdb/event-top= .c:461 #9=C2=A0 display_gdb_prompt (new_prompt=3D) at C:/src/repos/= binutils-gdb.git/gdb/event-top.c:428 #10 0x000000013fea4115 in captured_command_loop () at C:/src/repos/binutils= -gdb.git/gdb/main.c:472 #11 0x000000013fea5de5 in captured_main (data=3D0x24fa70) at C:/src/repos/b= inutils-gdb.git/gdb/main.c:1341 #12 gdb_main (args=3Dargs@entry=3D0x24fad0) at C:/src/repos/binutils-gdb.gi= t/gdb/main.c:1356 #13 0x0000000140692e27 in main (argc=3D2, argv=3D0x5c4cc0) at C:/src/repos/= binutils-gdb.git/gdb/gdb.c:32 > Anyway I am wondering if we can have gdb_rl_deprep_term_function call > rl_clear_signals and then reinstall the gdb signal handlers.=C2=A0 This i= dea > makes me wonder if we even need SetConsoleCtrlHandler at all -- maybe gdb > could just use signal after all. Good question, maybe it doesn't handle C-break as well? Hannes