Re: new-ui, the console, and synchronization by the front end

On 4/11/20 3:36 PM, Bob Rossi wrote:
> Hi,
> 
> I'm looking into using the new-ui feature with CGDB.
> 
> Historically, CGDB would only use the standard console
> and it would allow the user to send one command at a time
> to gdb. CGDB would often issue it's own commands
> between the user commands.
> 
> In the new-ui work flow, I believe I understand there
> are now two communication channels to gdb.
> - new-ui for CGDB to communicate with gdb using MI
> - standard console for the user to communicate with gdb

That's the main way to use it, yes.

> 
> Do I have this right? (If so, i have a few questions)
> 
> If the CGDB allows a command to get sent to the
> new-ui channel and to the standard console:
> - Does gdb run them at the same time or in series?

In series.  But that's a GDB implementation detail.  At some
point GDB could start processing commands in parallel, and
it should make no difference to clients.  At, when mi-async
is enabled.

> - Is there an ordering mechanism within gdb to determine
>   which is executed first?

No.  How could there be one?  GDB is listening to two
file descriptors for input, and whichever completes a whole
line of input first is processed first.

> - Can CGDB hook into gdb to run commands between
>   the user console commands? (For instance, 'up' in gdb doesn't
>   produce an mi async command to tell you the source file
>   position has changed. Annotate=1 will alert you of this.
>   So CGDB may want to run -file-list-exec-source-file
>   between each user command to get the new file position.)

Maybe you're using an old GDB.  Current GDB emits a =thread-selected
async notification in response to "up", and that notification
includes information about the current frame and source file
position.

Thanks,
Pedro Alves