From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 524433858D1E for ; Fri, 13 Oct 2023 12:25:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 524433858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 2C5861FDA1; Fri, 13 Oct 2023 12:25:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1697199920; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1DOMb+JSlckUTxriBz4/wJQR+JZ7J2L2pfPWKbnbcLM=; b=mzYn1Mk33E3HtXpL4XZUhg/kBsY2mcl9JdUli10QDl0AK4ZBPuiSypXLNSTB0MtIX0c6bU 7RORid71EQCEkvnYzl2GXUGQXEUg6C2QuFIAwPMoBU2FXn+UOkLutuSwzYA7UV1879N77L /DMSbVeTT6iTFDfncNDUU1Ab3KfMAiA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1697199920; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1DOMb+JSlckUTxriBz4/wJQR+JZ7J2L2pfPWKbnbcLM=; b=acAhjlZA4eLxugEsqJ5xE9fXF6gTdQW02du+g7HFBC0pY0eHzwR6RU5bNUM2xmHYChTNLQ OJiOyX3Xm9x+dIBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 129DA1358F; Fri, 13 Oct 2023 12:25:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 2r9eAzA3KWVYcAAAMHmgww (envelope-from ); Fri, 13 Oct 2023 12:25:20 +0000 Message-ID: <85e50aa7-94b7-46a9-bbd2-424c472f4ead@suse.de> Date: Fri, 13 Oct 2023 14:25:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] [gdb/cli] Allow source highlighting to be interrupted Content-Language: en-US From: Tom de Vries To: Tom Tromey Cc: gdb-patches@sourceware.org, Pedro Alves References: <20231011134247.3832-1-tdevries@suse.de> <87jzrtt7lp.fsf@tromey.com> <32a372df-e0c4-49c0-aeb7-97de208dc8a0@suse.de> In-Reply-To: <32a372df-e0c4-49c0-aeb7-97de208dc8a0@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -4.24 X-Spamd-Result: default: False [-4.24 / 50.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-3.00)[-1.000]; BAYES_HAM(-0.15)[68.53%]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On 10/11/23 20:11, Tom de Vries wrote: > On 10/11/23 19:02, Tom Tromey wrote: >>>>>>> "Tom" == Tom de Vries writes: >> >> Tom> Breakpoint 1, Solution::numOfSubarrays (this=0x7fffffffdbcf, >> arr=...) at test.cpp:56 >> Tom> ^Cwarning: Couldn't highlight source file >> /data/vries/gdb/test.cpp: Interrupted >> Tom> 56            return (int) t; >> Tom> (gdb) >> Tom> ... >> >> Tom> RFC: is the warning a good idea, or overkill? >> >> I'm on the fence, though I guess if it can't be done it might be nice if >> gdb kept track of this and just didn't try highlighting that file again. >> >> Tom> +class gdb_highlight_event_listener : public >> srchilite::HighlightEventListener >> Tom> +{ >> Tom> +public: >> Tom> +  void notify(const srchilite::HighlightEvent &event) override >> Tom> +  { >> Tom> +    if (check_quit_flag ()) >> Tom> +      { >> Tom> +    /* Got SIGINT, interrupt highlighting, it may take too >> long.  */ >> Tom> +    throw_quit ("Interrupted"); >> Tom> +      } >> >> Can the whole block just be "QUIT"? > > I tried that, and found that it doesn't work, which is why I came up > with this. > > QUIT calls maybe_quit: > ... > void > maybe_quit (void) > { >   if (!is_main_thread ()) >     return; > >   if (sync_quit_force_run) >     quit (); > >   quit_handler (); > } > ... > and since sync_quit_force_run == false, it calls quit_handler, which is > infrun_quit_handler. That one does nothing because > target_terminal::is_ours (): > ... > static void > infrun_quit_handler () > { >   if (target_terminal::is_ours ()) >     { >       /* Do nothing. > > >          default_quit_handler would throw a quit in this case, but if >          we're handling an event while we have the terminal, it means >          the target is running a background execution command, and >          thus when users press Ctrl-C, they're wanting to interrupt >          whatever command they were executing in the command line. >          E.g.: > > >           (gdb) c& >           (gdb) foo bar whatever > > >          That Ctrl-C should clear the input line, not interrupt event >          handling if it happens that the user types Ctrl-C at just the >          "wrong" time! > > >          It's as-if background event handling was handled by a >          separate background thread. > > >          To be clear, the Ctrl-C is not lost -- it will be processed >          by the next QUIT call once we're out of fetch_inferior_event >          again.  */ >     } > ... > > The highlight interruption scenario is not covered by the comment.  So > maybe that means that the function needs to be extended to handle it. > Alternatively, maybe it means that we need to have a different quit > handler while doing the highlighting. > > [ cc-ing Pedro since this is ^C related. ] > In the v2 ( https://sourceware.org/pipermail/gdb-patches/2023-October/203198.html ) I managed to use QUIT by temporarily installing the default_quit_handler. I hope that that's the appropriate way of handling this. Thanks, - Tom