Re: [RFC] [gdb/cli] Allow source highlighting to be interrupted

[Tom de Vries <tdevries@suse.de>]

On 10/11/23 19:02, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> 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<ctrl-c> 

 

          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. ]

Thanks,
- Tom