From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) by sourceware.org (Postfix) with ESMTPS id BAE7A384FEB3 for ; Fri, 9 Dec 2022 17:20:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BAE7A384FEB3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-io1-xd33.google.com with SMTP id i83so2369349ioa.11 for ; Fri, 09 Dec 2022 09:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=oZgcYsWDDJnGXjM1FwNDjyFMTKsujUhYKYY/Zt9brUs=; b=cfiiAIwDfm4ypCMkrlT5wbQDFmDmWe4+ChHU2+rVU4RU2VU1lVFjiGRKbd8AVwHKfB M26IhVBIcX+NxoRuKb7l8HVeTFh5k67uazsREro1HesP4RRwSHoD+bnf9g9bTvlFGZTS sZbYqYbr1rayWB3LVvksUmmlaxgP61tg2YyLltgaEL+8Re93F33dNcvXgkw0usf6VeSH FDHhAkvecE+bUEqD9/k7fvRJN6BQmThJTRqQ7Yg+NLmhD31E/M9d8ki8+fiQtsv0BYc1 86NqOlc8gJ+WtR7n8NiVv40a2zn/UNPdlmzFKnA/LPMLmt1Xr0fdTt2rzL6Jkw67QpoV 4n0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=oZgcYsWDDJnGXjM1FwNDjyFMTKsujUhYKYY/Zt9brUs=; b=E2w/SotaGsNbKHsNdk0laMQ5214kkFFYntrxc+eltw/ylV1PVRCk4VLqRFMaIP/d7v uo05sh81WTDEeZN27Qa7LTr7cDVlG/knXLr9XZP5wGuR1etooTDk23GycITMMT6DCpx+ ydhilpgIm0gHOfbPzMT6YFxlZMpLZsCiN/UA92UPfeud+1/ngjhD4mHatbUTvYbYgBYi 7SQWcm2l0wGMFPLKqqgLTWtg2FpNLoQVTjgGrLKg2B2k86/sv9oHuu5wwSvmDtcIdufN g1RJNEIDC2TUiCg06EY0fIYoM5iS8Od91+QffZPOxJnzQlS6RA2Rl6+N4U6O8wav6h5R pmTA== X-Gm-Message-State: ANoB5pmEB3cORWnk2Fd+W4I0/OslvFpZaDMwAfCOIXRuZRUxRs6V51J5 GMM94LWVJm8qx85rGCD+KlLumRdgS8QqKs6x X-Google-Smtp-Source: AA0mqf5n+b0Lbv1gJcDM/18KmplNVBcDkBvl3+hRKZvfjWaibRzkzArehYr7ZgXp9zPEN/HqyIsqdg== X-Received: by 2002:a6b:8fcd:0:b0:6e0:2988:dd98 with SMTP id r196-20020a6b8fcd000000b006e02988dd98mr4101163iod.2.1670606453977; Fri, 09 Dec 2022 09:20:53 -0800 (PST) Received: from murgatroyd (97-122-76-186.hlrn.qwest.net. [97.122.76.186]) by smtp.gmail.com with ESMTPSA id h5-20020a022b05000000b0038a5083cfa7sm600571jaa.88.2022.12.09.09.20.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Dec 2022 09:20:53 -0800 (PST) From: Tom Tromey To: Hannes Domani Cc: Tom Tromey , "gdb-patches@sourceware.org" Subject: Re: [PATCH 3/3] Fix control-c handling on Windows 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> X-Attribution: Tom Date: Fri, 09 Dec 2022 10:20:52 -0700 In-Reply-To: <1095715284.5500968.1670602756752@mail.yahoo.com> (Hannes Domani's message of "Fri, 9 Dec 2022 16:19:16 +0000 (UTC)") Message-ID: <87edt8ijd7.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: >> 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() returned 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 attach, 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. Maybe my theory about what's going on here is incorrect. Hannes> As far as I could tell, signal() calls SetConsoleCtrlHandler(), probably 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? If so then why didn't that work for gdb? 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. I somewhat suspect Python but I don't really know. >> I did try 'new-console on' with my (x86-64) build, and that worked fine. >> 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 x86_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() again, Hannes> overriding the SIGINT handler again, and everything is fine. Do you know where this happens? Anyway I am wondering if we can have gdb_rl_deprep_term_function call rl_clear_signals and then reinstall the gdb signal handlers. This idea makes me wonder if we even need SetConsoleCtrlHandler at all -- maybe gdb could just use signal after all. Tom