Re: [PATCH master+7.12 v2 2/3] Emit inferior, thread and frame selection events to all UIs

[Simon Marchi <simon dot marchi at ericsson dot com>]

On 16-09-14 02:30 PM, Pedro Alves wrote:
> Hi Simon,
> 
> On 09/14/2016 06:45 PM, Simon Marchi wrote:
>> From: Antoine Tremblay <antoine.tremblay@ericsson.com>
>>
>> With this patch, when an inferior, thread or frame is explicitly
>> selected by the user, notifications will appear on all CLI and MI UIs.
>> When a GDB console is integrated in a front-end, this allows the
>> front-end to follow a selection made by the user ont he CLI, and it
>> informs the user about selection changes made behind the scenes by the
>> front-end.
>>
>> This patch fixes PR gdb/20487.
>>
>> In order to communicate frame changes to the front-end, this patch adds
>> a new field to the =thread-selected event for the selected frame.  The
>> idea is that since inferior/thread/frame can be seen as a composition,
>> it makes sense to send them together in the same event.  The vision
>> would be to eventually send the inferior information as well, if we find
>> that it's needed, although the "=thread-selected" event would be
>> ill-named for that job.
> 
> Given per-inferior thread numbers, we could also say that we switch to
> thread 0 of inferior INF (i.e., "INF.0").  Then it wouldn't sound that
> strange, maybe.  The problem is that MI talks in terms of the global
> thread id, not the per-inferior id.
>
> Anyway, since is for machine consumption, odd naming should not
> be a big deal, IMO.

What you said lower (adding thread-group to =thread-selected) makes sense I think.

>> frame
>> -----
>>
>> 1. CLI command:
>>
>>      frame 1
>>
>>    MI event:
>>
>>      =thread-selected,id="3",frame={level="1",...}
>>
>> 2. MI command:
>>
>>      -stack-select-frame 1
>>
>>    CLI event:
>>
>>      #1  0x00000000004007f0 in child_function...
>>
> 
> I think it's likely that experience will show that will want to tweak
> what we print in the CLI in the future, along with whether
> we print at all, but that's fine for now.  Making all user-selection
> change handling be consistent makes sense.

Yep.

>> 3. MI command (CLI-in-MI):
>>
>>      frame 1
>>
>>    MI event/reply:
>>
>>      &"frame 1\n"
>>      ~"#1  0x00000000004007f9 in ..."
>>      =thread-selected,id="3",frame={level="1"...}
>>      ^done
>>
>> inferior
>> --------
>>
>> Inferior selection events only go from the console to MI, since there's
>> no way to select the inferior in pure MI.
>>
>> 1. CLI command:
>>
>>      inferior 2
>>
>>    MI event:
>>
>>      =thread-selected,id="3"
>>
>> Note that if the user selects an inferior that is not started or exited,
>> the MI doesn't receive a notification.  Since there is no threads to
>> select, the =thread-selected event does not apply...
> 
> We could solve that by adding the thread group id (inferior id) to
> the notification, I think:
> 
>  =thread-selected,id="3",thread-group="i1",frame="..."
> 
>  =thread-selected,id="0",thread-group="i2",frame="..."
> 
> ...
> 
> If you select an inferior that is not running yet, thread 0 is what
> you effectively get:
> 
> (gdb) p $_inferior
> $1 = 1
> (gdb) p $_thread
> $2 = 1
> (gdb) p $_gthread
> $3 = 1
> (gdb) add-inferior 
> Added inferior 2
> (gdb) inferior 2
> [Switching to inferior 2 [<null>] (<noexec>)]
> (gdb) p $_inferior
> $4 = 2
> (gdb) p $_thread
> $5 = 0
> (gdb) p $_gthread
> $6 = 0
> (gdb) 

That sounds good.  I think we can plan this for 7.13 though, the goal now is
to get the basic use cases working, while not breaking any previous ones.

>> @@ -2124,9 +2137,16 @@ mi_execute_command (const char *cmd, int from_tty)
>>    if (command != NULL)
>>      {
>>        ptid_t previous_ptid = inferior_ptid;
>> +      struct cleanup *cleanup = make_cleanup (null_cleanup, NULL);
>>  
>>        command->token = token;
>>  
>> +      if (command->cmd != NULL && command->cmd->suppress_notification != NULL)
>> +        {
>> +          make_cleanup_restore_integer (command->cmd->suppress_notification);
>> +          *command->cmd->suppress_notification = 1;
>> +        }
>> +
>>        if (do_timings)
>>  	{
>>  	  command->cmd_start = XNEW (struct mi_timestamp);
>> @@ -2161,10 +2181,15 @@ mi_execute_command (const char *cmd, int from_tty)
>>  	  /* Don't try report anything if there are no threads --
>>  	     the program is dead.  */
>>  	  && thread_count () != 0
>> -	  /* -thread-select explicitly changes thread. If frontend uses that
>> -	     internally, we don't want to emit =thread-selected, since
>> -	     =thread-selected is supposed to indicate user's intentions.  */
> 
> I'm still uneasy about this.  Do we now emit a =thread-selected
> event when the frontend uses -thread-select?  Is that a deliberate change?

No, if the MI command is -thread-select, it won't match the condition.  The last part
of the condition only matches "-interpreter-exec".  Note that an event is sent in
mi_cmd_thread_select if the thread has changed, but because of the suppression, we
don't get an MI event.

In the first version of the patch, we didn't send an event from mi_cmd_thread_select.
Instead, it relied on this line that was in the condition:

  || (command->op == MI_COMMAND && command->argc <= 1)

When running -thread-select, the execution would enter the "if" and send the event from
here.  I couldn't really explain that line though (what's the point of checking argc?
there might be some other MI commands that have two arguments and that might change the
thread...).  I thought it was cleaner to remove this line and to send the event from
mi_cmd_thread_select directly, as is done in thread_command for CLI.

However, this code in v2 is wrong, I miss any MI command that might change the thread
(which is kind of the point of this code).  For example
"-data-evaluate-expression start_thread()", when you have a breakpoint on "here" in this
code:

  #include <pthread.h>

  void here() {
  }

  void *func (void *v) {
  	here();
  	for (;;)
  }

  pthread_t thread;
  void start_thread(void) {
  	pthread_create(&thread, NULL, func, NULL);
  	sleep (1);
  }

  int main() {
  	for (;;)
  		sleep(1);
  	return 0;
  }

See lower for suggestion on how to fix it (and hopefully make the code look a bit better).

>> -	  && strcmp (command->command, "thread-select") != 0)
>> +	  /* For CLI commands "thread" and "inferior", the event is already sent
>> +	     by the command, so don't send it again.  */
>> +	  && ((command->op == CLI_COMMAND
>> +	       && strncmp (command->command, "thread", 6) != 0
>> +	       && strncmp (command->command, "inferior", 8) != 0)
>> +	      || (command->op == MI_COMMAND && command->argc > 1
>> +		  && strcmp (command->command, "interpreter-exec") == 0
>> +		  && strncmp (command->argv[1], "thread", 6) != 0
>> +		  && strncmp (command->argv[1], "inferior", 8) != 0)))
> 
> These "strncmp" calls return 0 when the command is "threadfoo"
> or "inferiorfoo"  I think we need to check the next character
> too, somehow?

I think too, we can change the

  strncmp (command->command, "thread", 6)

with

  strncmp (command->command, "thread ", 7)

and so on.

> 
> I think it doesn't make a difference for any of the current "thread"
> subcommands ("thread apply", etc.), so probably not a big deal.
> (though it'd be nice to clean it up sooner than later to avoid
> this getting forgotten and breaking in the future.)

I'll tackle the splitting of the user and internal selected thread right after
7.12 is out, it should get cleaned up then.

> But, I suspect that we end up suppressing this case:
> 
> (gdb) define thread-foo
>> thread $arg0
>> end
> (gdb) thread-foo 2
> 
> Contrived, but certainly not hard to imagine user-commands doing
> something useful along with changing the selected thread.
> 
> What happens in this case?

I think that's actually the opposite.  The purpose of this whole ugly condition
is to avoid sending a second event, if we removed that whole part with strcmp's,
we would end up sending events twice.  It would not be nice, but it would not be
as bad as not sending any event.

So if you use the "thread" command in a user-defined command, the thread command
code will still send an event on its own.  If the command is named foo:

  define foo
    thread $arg0
  end

then this code won't realize that the thread was switched by a command that already
sends an event on its own, and will send a second event.  I think we can live with
that for now.  If the command was named "threadfoo", then it would happen to match
the string comparison, and we wouldn't send a second event (not we if updated the
strcmp's as mentioned earlier).

As you said, thread sub-commands are probably ok, as they don't change the user
selected thread.


That big condition is clearly unclear though :).  I suggest breaking it in its own
function, where it will be more readable (even though not technically better):


/* Determine whether the parsed command already notifies the
   user_selected_context_changed observer.  */

static int
command_sends_thread_selected_event (struct mi_parse *command)
{
  if (command->op == CLI_COMMAND)
    {
      /* CLI commands "thread" and "inferior" already send it.  */
      return (strncmp (command->command, "thread ", 7) == 0
	      || strncmp (command->command, "inferior ", 9) == 0);
    }
  else /* MI_COMMAND */
    {
      if (strcmp (command->command, "interpreter-exec") == 0
	  && command->argc > 1)

	/* "thread" and "inferior" again, but through -interpreter-exec.  */
	return (strncmp (command->argv[1], "thread ", 7) == 0
		|| strncmp (command->argv[1], "inferior ", 9) == 0);

      else
	/* MI command -thread-select already sends it.  */
	return strcmp (command->command, "thread-select") == 0;
    }

  /* We should not get here...  */
  return 0;
}


And then the condition becomes readable, and we understand the intent:


	  /* If the command already reports the thread change, no need to do it
	     again.  */
	  && !command_sends_thread_selected_event (command))
	  ...


To address you uneasiness with -thread-select, let's see how that that code interacts
with that command.  First, an event about the thread change is sent in
mi_cmd_thread_select.  Then, command_sends_thread_selected_event will return true,
making us skip sending the event again.

WDYT?

Simon