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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bob Rossi
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

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?
- Is there an ordering mechanism within gdb to determine
  which is executed 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.)
- If not, CGDB historically would only allow one user command
  to be sent to GDB at a time. annotate=2,3 provided the
  console prompt hooks to determine when a new command was
  available. However, annotations produce a lot of issues
  and I would really like to get away from them permanently.

Any other general purpose feedback on this would be excellent!

Thanks,
Bob Rossi
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - gdb list mailing list
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

Reply | Threaded
Open this post in threaded view
|

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

Bob Rossi
On Sat, Apr 11, 2020 at 04:42:04PM +0100, Pedro Alves wrote:

> On 4/11/20 3:36 PM, Bob Rossi wrote:
> > - 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.

Hi Pedro,

I really appreciate the responses, very helpful!

The only remaining question I have is about preventing
the user from running more than one command at a time.

The only way I know to do that is to intercept each of the
commands a user sends and queue them in CGDB itself.
Then to use prompt annotations using annotate=2 or 3
to determine when the next command is ready by GDB.

Does anyone know of another way to accomplish this?

Thanks,
Bob Rossi
Reply | Threaded
Open this post in threaded view
|

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

Sourceware - gdb list mailing list
On 4/14/20 12:16 PM, Bob Rossi wrote:
> I really appreciate the responses, very helpful!

My pleasure.

> The only remaining question I have is about preventing
> the user from running more than one command at a time.

Can you clarify the use case here?  I'm not sure I understand
what you mean by this, or why you'd need to do anything special.
It should be no different from running GDB standalone in a
terminal.  What do you mean by more then one command at
a time?

>
> The only way I know to do that is to intercept each of the
> commands a user sends and queue them in CGDB itself.
> Then to use prompt annotations using annotate=2 or 3
> to determine when the next command is ready by GDB.
>
> Does anyone know of another way to accomplish this?
Thanks,
Pedro Alves